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

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

Posts Tagged ‘management’

CMMI DEV v1.3 – Количественное Управление Проектом

Posted by Шамрай Александр на Ноябрь 28, 2013

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

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

Назначение

Назначением Количественного Управления Проектом (КУП) является управление проектом на основе количественных показателей для достижения целей качества и выполнения процесса проекта.

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

Процессная область Количественное Управление Проектом включает в себя следующие мероприятия:

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

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

Определенный процесс проекта — это набор взаимосвязанных подпроцессов, которые образуют комплексный и последовательный процесс для проекта. Практики Комплексного Управления Проектом описывают установку определенного процесса проекта с использованием выбора и доводки процессов из набора стандартных процессов организации. (См. определение «определенный процесс» в глоссарии).

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

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

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

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

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

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

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

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

  • Функции проверки качества или контроля качества
  • Определение и улучшение процесса
  • Функции внутреннего исследования и разработки
  • Функции идентификации и управления рисками
  • Функции технологий исследования
  • Исследования рынка
  • Оценка удовлетворенности заказчиков
  • Проблемы отслеживания и отчетности

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

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

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

См. процессную область Измерения и Анализ для получения дополнительной информации о мероприятиях обеспечения измерений и анализа и предоставления результатов измерений.

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

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

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

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

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

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

  • СЦ 1 Подготовить Количественное Управление
    • СП 1.1 Устанавливайте Цели Проекта
    • СП 1.2 Составляйте Определенный Процесс
    • СП 1.3 Выбирайте Подпроцессы и Атрибуты
    • СП 1.4 Выбирайте Меры и Техники Аналитики
  • СЦ 2 Количественно Управлять Проектом
    • СП 2.1 Отслеживайте Выполнение Выбранных Подпроцессов
    • СП 2.2 Управляйте Выполнением Проекта
    • СП 2.3 Выполняйте Анализ Корневых Причин

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

СЦ 1 Подготовить Количественное Управление

Проведена подготовка для количественного управления.

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

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

СП 1.1 Устанавливайте Цели Проекта

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

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

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

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

1. Проектные цели качества и выполнения процесса

2. Оценка риска не достижения целей проекта

Подпрактики

1. Анализируйте организационные цели для качества и выполнения процесса.

Эта оценка гарантирует, что члены проекта понимают более широкой бизнес-контекст, в котором существует проект. Цели проекта для качества и выполнения процесса разрабатываются в контексте этих всеобъемлющих организационных целей.

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

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

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

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

  • Продолжительность
  • Предсказуемость
  • Надежность
  • Ремонтопригодность
  • Удобство использования
  • Своевременность
  • Функциональность
  • Точность

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

Определение и документирование целей проекта включают следующее:

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

Примеры поддающихся измерению атрибутов качества включают следующее:

  • Среднее время между сбоями
  • Количество и важность дефектов в выпущенном продукте
  • Использование критических ресурсов
  • Число и важность обращений заказчиков, относительно предоставляемых услуг

Примеры поддающихся измерению атрибутов выполнения процесса включают следующее:

  • Время цикла
  • Процент времени переработки
  • Процент дефектов удаленных путем мероприятий верификации продукта (возможно по типу верификации, таких как коллегиальные оценки и тестирование)
  • Уровень исправления дефектов
  • Количество и важность дефектов (или инцидентов) найденных в первый год после поставки продукта (или запуска сервиса)

Примеры проектных целей качества и выполнения процесса включают в себя:

  • Поддержка размера журнала запросов на изменение ниже планируемого значения.
  • Улучшение производительности в гибкой среде относительно планируемого значения к планируемому сроку.
  • Сокращение время простоя на x % к установленному сроку.
  • Поддержка изменения расписания ниже указанного процента.
  • Снижение стоимости всего жизненного цикла на указанный % к установленному сроку.
  • Сокращения количества дефектов в продукте, поставляемого заказчику, на 10% без влияния на стоимость.

4. Определяйте промежуточные цели для мониторинга прогресса в достижении целей проекта.

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

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

5. Определяйте риски, которые влияют на достижение проектных целей качества и выполнения процесса.

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

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

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

Разрешение конфликтов предполагает следующие виды мероприятий:

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

7. Устанавливайте трассировку проектных целей качества и выполнения процесса к их источникам.

Примеры источников цели включают следующее:

  • Требования
  • Цели качества и выполнения процесса организации
  • Цели качество и выполнения процесса заказчика
  • Бизнес-цели
  • Обсуждение с заказчиками и потенциальными заказчиками
  • Обследование рынка
  • Архитектура продукта

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

8. Определяйте и согласовывайте цели качества и выполнения процесса для поставщиков.

9. Пересматривайте проектные цели качества и выполнения процесса по мере необходимости.

СП 1.2 Составляйте Определенный Процесс

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

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

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

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

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

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

1. Критерии, используемые для оценки альтернатив для проекта

2. Альтернативные подпроцессы

3. Подпроцессы, которые должны быть включены в определенный процесс проекта

4. Оценка риска, влияющего на достижение целей проекта

Подпрактики

1. Устанавливайте критерии для использования при оценке альтернатив процесса для проекта.

Критерии могут быть основаны на следующем:

  • Цели качества и выполнения процесса
  • Доступность данных о выполнении процесса и важность данных для оценки альтернатив
  • Знакомство с альтернативой или альтернативными вариантами, аналогичными составляемым
  • Наличие моделей выполнения процессов, которые могут быть использованы в оценке альтернатив
  • Стандарты линейки продукта
  • Модели жизненного цикла проекта
  • Требования заинтересованных сторон
  • Законы и правила

2. Определяйте альтернативные процессы и подпроцессы для проекта.

Выявление альтернатив может включать одно или несколько из следующих действий:

  • Анализ базовых показателей выполнения организационных процессов для определения кандидата в подпроцессы, которые помогли бы достичь проектные цели качества и выполнения процесса
  • Выявление подпроцессов из набора стандартных процессов, а также с учетом процессов в библиотеке активов процессов, которые могут помочь в достижении целей организации в
  • Выявление процессов из внешних источников (например, других организаций, профессиональных конференций, научных исследований)
  • Регулировка уровня или глубины интенсивности, с которой применяется подпроцесс (описано более подробно в подпрактике ниже)

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

  • Количество и тип коллегиальных оценок, которые состоятся и когда
  • Количество усилий или календарного времени, затрачиваемого на конкретные задачи
  • Число и выбор вовлекаемых людей
  • Требования к уровню квалификации для выполнения конкретных задач
  • Избирательное применение специализированных методов сборки или верификации
  • Повторное использование решений и связанных с ними стратегий для смягчения последствий рисков
  • Атрибуты продуктов и процессов для измерения
  • Частота дискретизации для управления данными

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

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

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

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

4. Оценивайте альтернативные вспомогательные критерии.

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

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

5. Выбирайте альтернативные подпроцессы, которые лучше всего соответствуют критериям.

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

6. Оценивайте риски не достижения целей качества и выполнения процесса для проекта.

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

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

СП 1.3 Выбирайте Подпроцессы и Атрибуты

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

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

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

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

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

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

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

2. Выбранные подпроцессы

3. Атрибуты выбранных подпроцессов, которые помогают прогнозировать будущее выполнение проекта

Подпрактики

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

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

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

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

Примеры критериев, используемых для выбора подпроцессов:

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

3. Выбирайте подпроцессы с помощью определенных критериев.

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

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

4. Определяйте атрибуты продукта и процесса, которые должны контролироваться.

Эти атрибуты были определены в рамках выполнения предыдущих подпрактик.

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

Примеры атрибутов продукта и процесса включают в себя следующее:

  • Усилия, применяемые для выполнения подпроцесса
  • Скорость, на которой выполняется подпроцесс
  • Время цикла для элементов процесса, которые составляют подпроцесс
  • Ресурсы или материалы, использованных в качестве входных для подпроцесса
  • Уровень квалификации сотрудника, выполняющего подпроцесс
  • Качество рабочей среды, используемой для выполнения подпроцесса
  • Объем артефактов подпроцесса на выходе (например, промежуточные рабочие продукты)
  • Качество атрибутов подпроцесса на выходе (например, надежность, тестируемость)

СП 1.4 Выбирайте Меры и Техники Аналитики

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

См. процессную область Измерения и Анализ для получения дополнительной информации о мероприятиях обеспечения измерений и анализа и предоставлении результатов измерений.

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

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

2. Трассировка мер с проектными целями качества и выполнения процесса

3. Цели качества и выполнения процесса для выбранных подпроцессов и их атрибутов

4. Базовые показатели выполнения процесса и модели для использования в рамках проекта

Подпрактики

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

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

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

Общие меры могут классифицироваться линейкой продукта или другими критериями стратификации.

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

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

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

При выборе мер, имейте в виду следующие соображения:

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

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

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

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

  • Поддержка уровня рецензирования кода от 75 до 100 строк кода в час
  • Выдерживать длительность сессий сбора требования до трех часов
  • Выдерживать скорость тестирования на указанное количество тестовых случаев в день
  • Поддержка уровень переделки ниже указанного процента
  • Поддержка производительности в генерировании вариантов использования на один день
  • Выдерживать сложность проектирования (уровень разветвления) ниже заданного порогового значения

6. Определяйте статистические и другие количественные методы для использования в количественном управлении.

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

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

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

Примеры графических отображений:

  • Диаграммы рассеивания
  • Гистограммы
  • Ящик с усами
  • Графики выполнения
  • Диаграммы Исикавы

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

  • Учетные листы
  • Схемы классификации (например, Ортогональная Классификация Дефектов)

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

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

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

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

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

Этот инструментарий основан на следующем:

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

9. Пересматривайте меры и методы статистического анализа по мере необходимости.

СЦ 2 Количественно Управлять Проектом

Проект управляется количественно.

Количественное управление проектом включает в себя использование статистических и других количественных методов для выполнения следующих задач:

  • Мониторинг выбранных подпроцессов с использованием статистических и других количественных методов
  • Определение удовлетворены ли проектные цели качества и выполнения процесса
  • Выполнение анализа корневых причин выбранных проблем для устранения недостатков

СП 2.1 Отслеживайте Выполнение Выбранных Подпроцессов

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

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

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

1. Естественные границы выполнение процесса для каждого выбранного атрибута подпроцессов

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

Подпрактики

1. Собирайте данные, как это определено выбранными мерами, подпроцессов по мере их выполнения.

2. Контролируйте колебания и стабильность выбранных подпроцессов и устраняйте недостатки.

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

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

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

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

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

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

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

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

Некоторые действия могут включать использование анализа корневых причин, который описан далее в СП 2.3.

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

СП 2.2 Управляйте Выполнением Проекта

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

См. процессную область Измерение и Анализа для получения дополнительной информации о мероприятиях обеспечения измерений и анализа и предоставлении результатов измерений.

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

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

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

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

1. Результаты прогнозов достижения относительно целей качества и выполнения процесса проекта

2. Графическое отображение и табулирование данных для других подпроцессов, поддерживающих количественное управление

3. Оценка рисков не достижения целей качества и выполнения процесса проекта

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

Подпрактики

1. Периодически оценивайте выполнение подпроцессов.

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

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

2. Отслеживайте и анализируйте прогресс поставщиков в достижении их целей качества и выполнения процесса.

3. Периодически рассматривайте и анализируйте фактические результаты, достигнутые в отношении установленных временных целей.

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

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

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

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

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

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

Примеры источников рисков включают следующее:

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

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

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

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

  • Изменение целей качества и выполнения процесса так, чтобы они находились в ожидаемых пределах определенного процесса проекта
  • Улучшение реализации определенного процесса проекта
  • Принятие новых подпроцессов и технологий, которые имеют потенциал для удовлетворения целей и управления связанными рисками
  • Выявление рисков и стратегии смягчения последствий риска для устранения недостатков
  • Завершение проекта

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

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

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

СП 2.3 Выполняйте Анализ Корневых Причин

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

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

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

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

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

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

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

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

См. процессную область Измерения и Анализ для получения дополнительной информации о мероприятиях обеспечения измерения и анализа и предоставлении результатов измерений.

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

1. Измерения и анализ (включая статистический анализ) выполнения подпроцесса и проекта записанные в организационном репозитории мер

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

3. Выявленные корневые причины и потенциальные мероприятия

Подпрактики

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

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

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

2. Выявляйте и анализируйте потенциальные мероприятия.

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

4. Оценивайте воздействие принимаемых мер на выполнение подпроцессов.

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

Posted in CMMI, Стандарты и методологии | Отмечено: , , , | Leave a Comment »

CMMI DEV v1.3 –Комплексное Управление Проектом

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

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

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

Назначение

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

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

Комплексное управление проектом включает в себя следующие мероприятия:

  • Установка определенного процесса проекта на начало проекта с использованием адаптации набора стандартных процессов организации
  • Управление проектом с использованием определенного процесса проекта
  • Установка рабочей среды для проекта, основанного на стандартах рабочей среды организации
  • Создание команды, которой поручено достичь цели проекта
  • Использование и способствование активам организационного процесса
  • Обеспечение возможности соответствующим заинтересованным сторонам быть определенными, принятыми во внимание и, при необходимости, привлеченными в ходе проекта
  • Обеспечение того, чтобы соответствующие заинтересованные стороны (1) выполняли свои задачи координировано и своевременно; (2) были согласованы с требования проекта, планами, целями, проблемами и рисками; (3) выполняли свои обязательства по выполнению; и (4) выявляли, отслеживали и решали проблемы координации

Комплексный и определенный процесс, который адаптирован из набора стандартных процессов организации, называется определенный процесс проекта. (См. определение «проект» в глоссарии.)

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

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

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

  • Мероприятия по разработке (например, разработка требований, проектирование, верификация)
  • Сервисные мероприятия (например, поставка, служба обслуживания, операции, контакты с клиентами)
  • Мероприятия по приобретению (например, предложения, мониторинг соглашений, передача в эксплуатацию)
  • Мероприятия по поддержке (например, управление конфигурацией, документация, маркетинг, обучение)

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

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

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

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

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

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

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

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

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

  • СЦ 1 Использовать Определенный Процесс Проекта
    • СП 1.1 Устанавливайте Определенный Процесс Проекта
    • СП 1.2 Используйте Активы Организационного Процесса для Планирования Проектных Мероприятий
    • СП 1.3 Устанавливайте Рабочую Среду Проекта
    • СП 1.4 Объединяйте Планы
    • СП 1.5 Управляйте Проектом Используя Объединенные Планы
    • СП 1.6 Устанавливайте Команды
    • СП 1.7 Содействуйте Активам Организационного Процесса
  • СЦ 2. Координировать и Сотрудничать с Соответствующими Заинтересованными Сторонами
    • СП 2.1 Управляйте Участием Заинтересованных Сторон
    • СП 2.2 Управляйте Зависимостями
    • СП 2.3 Решайте Проблемы Координации

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

СЦ 1 Использовать Определенный Процесс Проекта

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

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

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

СП 1.1 Устанавливайте Определенный Процесс Проекта

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

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

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

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

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

Определенный процесс проекта основывается на следующих факторах:

  • Требования заинтересованных сторон
  • Обязательства по выполнению
  • Потребности и цели организационного процесса
  • Набор стандартных процессов организации и принципы адаптации
  • Операционная среда
  • Бизнес-среда

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

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

1. Определенный процесс проекта

Подпрактики

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

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

  • Размер и сложность проекта
  • Стратегия проекта
  • Опыт и знания персонала в реализации процесса
  • Ограничения, такие как время цикла и приемлемые уровни дефектов
  • Наличие заказчиков для ответов на вопросы и обеспечение обратной связи для инкрементов
  • Ясность требований
  • Ожидания заказчика

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

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

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

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

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

Другие артефакты могут включать в себя следующее:

  • Документы с извлеченными уроками
  • Шаблоны
  • Примеры документов
  • Модели оценки

5. Документируйте определенный процесс проекта.

Определенный процесс проекта охватывает все виды деятельности по проекту и его интерфейсы для соответствующих заинтересованных сторон.

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

  • Планирование проекта
  • Мониторинг проекта
  • Управление поставщиками
  • Обеспечение качества
  • Управление рисками
  • Анализ и принятие решений
  • Разработка требований
  • Управление требованиями
  • Управление конфигурацией
  • Разработка и поддержка продукта
  • Рецензирование кода
  • Предложения

6. Проводите коллегиальные оценки определенного процесса проекта.

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

7. Пересматривайте определенный процесс проекта по мере необходимости.

СП 1.2 Используйте Активы Организационного Процесса для Планирования Проектных Мероприятий

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

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

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

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

1. Оценки проекта

2. Планы проекта

Подпрактики

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

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

2. Используйте хранилище измерений организации для оценки планирования параметров проекта.

Эта оценка обычно включает в себя следующее:

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

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

  • Рабочий продукт и атрибуты задачи
  • Область применения
  • Опыт людей
  • Подходы проектирования и разработки
  • Условия эксплуатации

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

  • Размер рабочих продуктов или другие атрибуты рабочих продуктов
  • Трудозатраты
  • Стоимость
  • Рабочий график
  • Кадровое обеспечение
  • Время отклика
  • Сервисные мощности
  • Работы поставщиков
  • Дефекты

СП 1.3 Устанавливайте Рабочую Среду Проекта

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

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

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

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

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

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

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

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

1. Оборудование и инструменты для проекта

2. Руководства по инсталляции, эксплуатации и обслуживанию для рабочей среды проекта

3. Пользовательские опросы и результаты

4. Журналы использования, выполнения и обслуживания

5. Сервисы поддержки для рабочей среды проекта

Подпрактики

1. Планируйте, проектируйте и инсталлируйте рабочую среду для проекта.

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

Может быть необходим поиск компромисса между атрибутами качества, затратами и рисками. Ниже приведены примеры каждого из них:

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

Примеры оборудования и инструментов включают в себя следующее:

  • Офисное программное обеспечение
  • Программного обеспечения поддержки принятия решений
  • Инструменты для управления проектами
  • Оборудование тестирования и оценки
  • Инструменты разработки и управления требованиями
  • Инструменты для управления конфигурацией
  • Инструменты оценки
  • Инструменты интеграции
  • Инструменты автоматизированного тестирования

2. Обеспечивайте текущее обслуживание и операционную поддержку рабочей среды проекта.

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

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

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

3. Поддерживайте квалификацию компонентов рабочей среды проекта.

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

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

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

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

СП 1.4 Объединяете Планы

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

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

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

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

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

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

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

1. Объединенные планы

Подпрактики

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

Другие планы, которые влияют на план проекта, могут включать в себя следующее:

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

2. Интегрируйте в план проекта определения мер и мероприятий измерений по управлению проектом.

Примеры мер, которые могут быть включены, включают следующие:

  • Общие комплекс мер организации
  • Дополнительные специфические для проекта меры

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

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

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

Примеры рисков интерфейсов продукта и проекта включают следующее:

  • Неполные описания интерфейса
  • Отсутствие инструментов, поставщиков или оборудования тестирования
  • Отсутствие готовых коммерческих компонентов
  • Недостаточное или неэффективное командное взаимодействие

4. Готовьте календарные планы для задач в последовательности, которая учитывает критическую разработку, факторы поставки и риски проекта.

Примеры факторов, которые учитываются при планировании, включают следующее:

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

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

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

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

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

7. Устанавливайте объективные входные и выходные критерии для авторизации начала и завершения задач, описанных в структуре декомпозиции работ (СДР).

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

8. Убедитесь, что план проекта соответствующим образом совместим с планами соответствующих заинтересованных сторон.

Обычно план и изменения в план должны быть рассмотрены на совместимость.

9. Определяйте, как будут решены конфликты, которые возникают между соответствующими заинтересованными сторонами.

СП 1.5 Управляйте Проектом Используя Объединенные Планы

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

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

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

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

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

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

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

2. Собранные меры (например, фактические) и информация или отчеты о состоянии

3. Пересмотренные требования, планы и обязательства по выполнению

4. Объединенные планы

Подпрактики

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

Эта задача обычно включает в себя следующие мероприятия:

  • Включение артефактов из библиотеки активов организационных процессов в проект по мере необходимости
  • Использование извлеченных уроков из библиотеки активов организационных процессов для управления проектом

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

Эта задача обычно включает в себя следующие мероприятия:

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

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

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

См. процессную область Измерение и Анализа для получения дополнительной информации о получении данных измерений и анализа данных измерений.

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

Эта оценка включает в себя согласование с потребностями и целями процесса организации.

Примеры действий, которые обеспечивают соответствие, включают следующее:

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

5. Рассматривайте причины выбранных проблем, которые могут повлиять на цели проекта.

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

СП 1.6 Устанавливайте Команды

Устанавливайте и поддерживайте команды.

Управление проект выполняется с использованием команд, которые отражают организационные правила и руководящие принципы для структурирования, формирования и функционирования команды. (См. определение «команда» в глоссарии.)

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

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

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

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

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

1. Документальное общее видение

2. Список членов назначенных в каждой команде

3. Устав команды

4. Периодические отчеты о состоянии команды

Подпрактики

1. Устанавливайте и поддерживайте общее видение проекта.

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

2. Устанавливайте и поддерживайте структуры команд.

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

3. Устанавливайте и поддерживайте каждую команду.

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

4. Периодически оценивайте структуру и состав команды.

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

СП 1.7 Дополняйте Активы Организационного Процесса

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

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

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

Это специфическая практика затрагивает включаемую информацию от процессов из определенных процессов проекта в активы организационных процессов.

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

1. Предложения о совершенствовании активов организационных процессов

2. Фактические меры процесса и продукта собранные из проекта

3. Документация (например, примерные описания процесса, планы, учебные программы, контрольные списки, полученные уроки)

4. Артефакты процесса, связанные с адаптацией и реализацией набора стандартных процессов организации на проект

Подпрактики

1. Предлагайте усовершенствования активов организационных процессов.

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

См. процессную область Измерение и Анализ для получения дополнительной информации о получении данных измерений.

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

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

Эти меры процесса и продукта обычно включают в себя следующее:

  • Плановые данные
  • Перепланированные данные

Примеры данных, записанных в рамках проекта, включают следующее:

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

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

Примеры документации включают следующее:

  • Примеры описания процесса
  • Материалы обучения
  • Примеры планов
  • Шаблоны контрольных списков
  • Шаблоны проектных хранилищ
  • Конфигурации инструментов

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

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

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

СЦ 2 Координация и Сотрудничество с Соответствующими Заинтересованными Сторонами

Ведется координация и сотрудничество между проектом и соответствующими заинтересованными сторонами.

СП 2.1 Управляйте Участием Заинтересованных Сторон

Управление вовлечением соответствующих заинтересованных сторон в проекте.

Участие заинтересованных сторон управляется в соответствии с комплексным планом проекта и определенным процессом.

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

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

1. Программа и календарные графики для совместной деятельности

2. Рекомендации по решению проблем соответствующих заинтересованных сторон

3. Документированные проблемы (например, проблемы с требованиями заинтересованных сторон, требованиями к продукту и компонентам продукта, архитектурой продукта, проектированием продукта)

Подпрактики

1. Координируйте с соответствующими заинтересованными сторонами кто должен участвовать в мероприятиях проекта.

Соответствующие заинтересованные стороны уже должны быть определены в плане проекта.

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

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

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

Эта задача обычно включает в себя следующее:

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

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

СП 2.2 Управляйте Зависимостями

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

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

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

2. Критические зависимости

3. Обязательства по выполнению для решения важнейших зависимостей

4. Состояние критических зависимостей

Подпрактики

1. Проводите обзоры с соответствующими заинтересованными сторонами.

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

3. Устанавливайте желаемые сроки и плановые сроки для каждой критической зависимости на основе календарного графика проекта.

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

5. Документируйте критические зависимости и обязательства по выполнению.

Документация обязательств по выполнению, как правило, включает следующее:

  • Описание обязательства по выполнению
  • Определение кто взял на себя обязательство по выполнению
  • Определение кто несет ответственность за удовлетворение обязательств по выполнению
  • Определение, когда обязательства по выполнению будут выполнены
  • Определение критериев для определения было ли обязательство по выполнению выполнено

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

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

Отслеживание критических зависимостей обычно включает в себя следующее:

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

СП 2.3 Решайте Проблемы Координации

Решайте проблемы с соответствующими заинтересованными сторонами.

Примеры вопросов координации включают следующее:

  • Требования к продукту и компонентам продукта и дефекты проектирования
  • Запаздывающие критические зависимости и обязательства по выполнению
  • Проблемы на уровне продукта
  • Недоступность критических ресурсов или персонала

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

1. Проблемы координации с соответствующими заинтересованными сторонами

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

Подпрактики

1. Выявляйте и документируйте проблемы.

2. Уведомляйте о проблемах соответствующие заинтересованные стороны.

3. Решайте проблемы с соответствующими заинтересованными сторонами.

4. Эскалируйте на соответствующих менеджеров проблемы, которые не были решены с соответствующими заинтересованными сторонами.

5. Отслеживайте проблемы до их закрытия.

6. Сообщайте соответствующим заинтересованным сторонам о состоянии и решении возникших проблем.

Posted in CMMI, Стандарты и методологии | Отмечено: , , , , , , , | Leave a Comment »

CMMI DEV v1.3 – Управление Рисками

Posted by Шамрай Александр на Август 12, 2011

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

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

Назначение

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

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

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

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

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

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

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

Управление рисками можно разделить на следующие части:

  • Определение стратегии управления рисками
  • Выявление и анализ рисков
  • Обработка идентифицированных рисков, в том числе реализация планов смягчения рисков по мере необходимости

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

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

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

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

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

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

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

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

  • СЦ 1 Подготовиться к Управлению Рисками
    • СП 1.1 Выявляйте Источники и Категории Рисков
    • СП 1.2 Определяйте Параметры Рисков
    • СП 1.3 Устанавливайте Стратегию Управления Рисками
  • СЦ 2. Идентифицировать и Проанализировать Риски
    • СП 2.1 Идентифицируйте Риски
    • СП 2.2 Оценивайте, Устанавливайте Категории и Приоритеты для Рисков
  • СЦ 3 Смягчить Риски
    • СП 3.1 Разрабатывайте План по Смягчению Риска
    • СП 3.2 Реализуйте План по Смягчению Риска

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

СЦ 1 Подготовиться к Управлению Рисками

Проведена подготовка к управлению рисками.

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

СП 1.1 Определяйте Источники и Категории Рисков

Определяйте источники и категории рисков.

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

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

1. Списки источников рисков (внешние и внутренние)

2. Список категорий рисков

Подпрактики

1. Определяйте источники рисков.

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

Типичные внутренние и внешние источники рисков включают следующее:

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

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

2. Определяйте категории рисков.

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

Следующие факторы могут быть учтены при определении категории рисков:

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

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

СП 1.2 Определяйте Параметры Рисков

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

Параметры для оценки, установки категории и приоритетов рисков включают в себя следующее:

  • Вероятность риска (т.е. вероятность возникновения риска)
  • Последствия риска (то есть, влияние и серьезность, вызываемые риском)
  • Пороговые значения для запуска мероприятий по управлению

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

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

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

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

1. Критерии для оценки риска, установки категории и приоритетов

2. Требования к управлению рисками (например, уровни контроля и утверждения, интервалы переоценки)

Подпрактики

1. Определяйте последовательные критерии для оценки и установки количественной вероятности и серьезности риска.

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

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

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

Примеры порогов включают следующее:

  • Пороговые значения по проекту могут быть установлены для привлечения старшего руководства, когда затраты по продукту превышают на 10 процентов целевые затраты, или когда индекс выполнения бюджета опускается ниже 0,95.
  • Пороговые значения графика работ может быть установлены для привлечения старшего руководства, когда индекс выполнения графика работ опускается ниже 0,95.
  • Пороговые значения производительности могут быть установлены для привлечения старшего руководства, когда указанные ключевые элементы (например, загрузка процессора, среднее время отклика) превышают 125 процентов установленные при проектировании.

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

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

СП 1.3 Устанавливайте Стратегию Управления Рисками

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

Всесторонняя стратегия управления рисками затрагивает такие элементы как нижеприведенные:

  • Объем трудозатрат управления рисками
  • Методы и инструменты, которые будут использоваться для выявления рисков, анализа рисков, смягчения рисков, мониторинга рисков и информирования
  • Специфические для проекта источники рисков
  • Каким образом риски будут организовываться, определяться категории, сравниваться и консолидироваться
  • Параметры, используемые для принятия мер по выявленным рискам, в том числе вероятность, последствия и пороговые значения
  • Техники смягчения рисков, которые будут использоваться, например, прототипирование, пилотирование, симуляции, проектирование альтернатив или эволюционная разработка
  • Определение мер риска, используемых для отслеживания состояния рисков
  • Временные интервалы для мониторинга рисков или переоценки

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

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

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

1. Стратегия управления рисками проекта

СЦ 2 Идентифицировать и Проанализировать Риски

Риски выявлены и проанализированы для определения их относительной важности.

Уровень риска влияет на ресурсы, выделяемые для обработки риска, и требуемое внимание, которое выделяется для управления.

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

СП 2.1 Идентифицируйте Риски

Идентифицируйте и документируйте риски.

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

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

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

Много методов используется для идентификации рисков. Типичные методы идентификации включают следующее:

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

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

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

Подпрактики

1. Определяйте риски, связанные с затратами, сроками и выполнением.

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

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

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

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

Риски, связанные с выполнением, могут включать в себя следующие риски:

  • Требования
  • Анализ и проектирование
  • Применение новых технологий
  • Физические размеры
  • Вид
  • Вес
  • Производство и изготовление
  • Режимы и эксплуатация продукта в отношении функциональных возможностей и атрибутов качества
  • Верификация
  • Валидация
  • Признаки выполнения поддержки

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

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

Примерами таких других рисков включают следующие риски:

  • Забастовки
  • Уменьшение источников поставок
  • Время технологического цикла
  • Конкуренция

2. Рассматривайте элементы среды, которые могут повлиять на проект.

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

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

4. Рассматривайте все элементы плана проекта в рамках определения рисков, чтобы гарантировать, что все аспекты проекта были рассмотрены.

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

5. Документируйте контекст, условия и потенциальные последствия каждого риска.

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

6. Определяйте соответствующие заинтересованные стороны, связанные с каждым риском.

СП 2.2 Оценивайте, Устанавливайте Категории и Приоритеты для Рисков

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

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

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

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

1. Список рисков и назначенные на них приоритеты

Подпрактики

1. Оценивайте идентифицированные риски, используя установленные параметры рисков.

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

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

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

Пример категории последствия, включают следующее:

  • Низкое
  • Среднее
  • Высокое
  • Незначительное
  • Маргинальное
  • Значительное
  • Критическое
  • Катастрофическое

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

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

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

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

3. Устанавливайте приоритетность рисков для смягчения их последствий.

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

СЦ 3 Смягчить Риски

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

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

СП 3.1 Разрабатывайте Планы по Смягчению Рисков

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

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

Варианты обработки рисков, как правило, включают альтернативы, такие как следующие:

  • Снижение рисков: изменение или понижение требований в то же время удовлетворение потребностей конечного пользователя
  • Контроль рисков: принятие активных мер, чтобы минимизировать риски
  • Передача рисков: перераспределение требований для снижения рисков
  • Мониторинг рисков: наблюдение и периодический пересмотр изменения в рисках в заданных параметрах риска
  • Признание рисков: признание риска, но не принятие никаких мер

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

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

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

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

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

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

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

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

2. Планы снижение рисков

3. Планы

4. Список тех, кто отвечает за отслеживание и устранение каждого риска

Подпрактики

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

Уровень риска (полученный с использованием модели риска) является мерой сочетания неопределенности достижения цели с последствиями неудачи для достижения цели.

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

2. Определяйте лицо или группу, ответственную за решение каждого риска.

3. Определяйте затраты и выгоды от реализации плана снижения рисков по каждому риску.

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

4. Разрабатывайте общий план снижения рисков по проекту для управления реализацией отдельных планов снижения рисков и последствий риска.

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

5. Разрабатывайте планы действий для отдельных критических рисков в случае реализации их воздействия.

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

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

СП 3.2 Реализуйте План по Смягчению Риска

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

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

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

1. Обновленные списки состояний рисков

2. Обновленные оценки вероятности, последствий и пороговых значений рисков

3. Обновленный список вариантов обработки рисков

4. Обновленный список действий, предпринятых для обработки рисков

5. Планы смягчения рисков для условий обработки рисков

Подпрактики

1. Отслеживайте состояние рисков.

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

Должны быть использованы механизмы мониторинга.

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

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

3. Выполняйте выбранные опции обработки риска, когда риск превышает определенное пороговое значение.

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

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

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

5. Обеспечивайте постоянное подтверждение исполнения ресурсами для каждого плана для успешного выполнения мероприятий по обработке риска.

6. Собирайте показатели выполнения мероприятий по обработке риска.

Posted in CMMI, Стандарты и методологии | Отмечено: , , , , , | 3 комментария »

CMMI DEV v1.3 – Управление Соглашениями с Поставщиками

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

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

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

Назначение

Назначением Управление Соглашениями с Поставщиками (УСП) является управление приобретением продуктов и услуг от поставщиков.

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

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

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

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

Процессная область Управление Соглашениями с Поставщиками включает в себя следующие мероприятия:

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

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

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

  • Подсистемы (например, навигационная система в самолете)
  • Программное обеспечение
  • Аппаратное обеспечение
  • Документация (например, монтажная, операционная и руководство пользователя)
  • Детали и материалы (например, датчики, переключатели, колеса, сталь, сырье)

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

Как правило, продукты, приобретаемые для проекта, определяются на ранних стадиях планирования и разработки.

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

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

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

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

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

Связанные процессы

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

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

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

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

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

  • СЦ 1 Заключить Соглашение с Поставщиком
    • СП 1.1 Определяйте Тип Поставки
    • СП 1.2 Выбирайте Поставщика
    • СП 1.3 Устанавливайте Соглашение с Поставщиком
  • СЦ 2 Выполнить Соглашение с Поставщиком
    • СП 2.1 Выполняйте Соглашение с Поставщиком
    • СП 2.2 Утверждайте Приобретаемый Продукт
    • СП 2.3 Обеспечивайте Доставку Продукта

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

СЦ 1 Заключить Соглашение с Поставщиком

Соглашения с поставщиками заключены и поддерживаются.

СП 1.1 Определяйте Тип Поставки

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

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

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

Примеры типов поставки включают следующее:

  • Покупка измененных готовых коммерческих продуктов имеющих существенное значение для проекта
  • Получение продуктов через соглашение с поставщиком
  • Получение продуктов от внутреннего поставщика
  • Получение продуктов от заказчика
  • Получение продуктов от предпочтительного поставщика
  • Объединение некоторых из вышеупомянутых (например, заключение контракта на модификацию готового коммерческого продукта, совместная доработка отличающихся бизнес частей продукта с внешним поставщиком)

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

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

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

СП 1.2 Выбирайте Поставщика

Выбирайте поставщиков на основе оценки их способности удовлетворить установленным требованиям и критериям.

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

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

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

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

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

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

1. Исследования рынка

2. Список кандидатов поставщиков

3. Список предпочтительных поставщиков

4. Торговые исследования или другая информация для оценки критериев, преимуществ и недостатков кандидата поставщиков и для рационального выбора поставщиков

5. Материалы и требования по ходатайству

Подпрактики

1. Устанавливайте и документируйте критерии для оценки потенциальных поставщиков.

2. Выявляйте потенциальных поставщиков и распространяйте тендерные материалы и требования к ним.

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

3. Оценивайте заявки в соответствии с критериями оценки.

4. Оценивайте риски, связанные с каждым предложенным поставщиком.

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

5. Оценивайте предлагаемые поставщиком возможности для выполнения работы.

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

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

Когда оценивается измененный готовый коммерческий продукт, рассматривайте следующее:

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

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

6. Выберите поставщика.

СП 1.3 Устанавливайте Соглашение с Поставщиком

Устанавливайте и поддерживайте соглашение с поставщиком.

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

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

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

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

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

1. Устав работ

2. Контракты

3. Меморандум о соглашении

4. Лицензионное соглашение

Подпрактики

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

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

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

2. Документируйте, что проект будет предоставлять поставщику.

Включая следующие:

  • Средства для снабжения проекта
  • Документация
  • Услуги

3. Документируйте соглашение с поставщиком.

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

Как правило, эта подпрактика включает в себя следующие задачи:

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

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

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

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

5. Удостоверьтесь, что все стороны соглашения с поставщиком понимают и согласны на все требования перед началом реализации соглашения или любого изменения.

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

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

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

СЦ 2 Выполнить Соглашение с Поставщиком

Соглашения с поставщиками выполнены обеими сторонами и проектом и поставщиком.

СП 2.1 Выполняйте Соглашение с Поставщиком

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

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

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

1. Отчеты поставщика о ходе работ и измерениях выполнения

2. Рецензия поставщика для материалов и отчетов

3. Действия, отслеженные до их закрытия

4. Поставки продукта и документации

Подпрактики

1. Следите за прогрессом и выполнением работ поставщиком (например, выполнение графика, трудозатрат, затрат, технических работ), как это определено в соглашении с поставщиком.

2. Выбирайте, следите и анализируйте процессы, используемые поставщиком, как определено в соглашении с поставщиком.

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

3. Выбирайте и оценивайте рабочие продукты от поставщика, как определено в соглашении с поставщиком.

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

4. Проводите анализ с поставщиком, как определено в соглашении с поставщиком.

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

Анализ охватывает формальный и неформальный анализ и включает в себя следующие шаги:

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

5. Проводите технический анализ с поставщиком, как определено в соглашении с поставщиком.

Технический анализ обычно включает в себя следующее:

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

6. Проводите управленческий анализ с поставщиком, как определено в соглашении с поставщиком.

Управленческий анализ обычно включает следующее:

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

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

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

8. Выполняйте мониторинг рисков, связанных с поставщиками, и предпринимайте корректирующие действия по необходимости.

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

СП 2.2 Утверждайте Приобретаемый Продукт

Проверяйте, что поставщик выполнил соглашение перед приемкой приобретенного продукта.

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

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

1. Процедуры приемки

2. Результаты приемочного анализа или испытаний

3. Отчеты по несоответствию или планы корректирующих действий

Подпрактики

1. Определяйте процедуру приемки.

2. Анализируйте и получайте согласие от соответствующих заинтересованных сторон на приемочные процедуры перед приемочным анализом или тестами.

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

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

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

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

5. Документируйте результаты приемочного анализа или теста.

6. Устанавливайте план действий и получайте согласие поставщика на принятие действий для корректировки приобретаемых рабочих продуктов, которые не прошли их приемочный анализ или тест.

7. Определяйте, документируйте, а также отслеживайте действия до их закрытия.

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

СП 2.3 Обеспечивайте Доставку Продукта

Проверяйте доставку приобретаемых продуктов от поставщиков.

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

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

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

1. Планы доставки

2. Отчеты по обучению

3. Отчеты по поддержке и обслуживанию

Подпрактики

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

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

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

Posted in CMMI, Стандарты и методологии | Отмечено: , , , , , , , | 2 комментария »

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. Инициируйте любые необходимые корректирующие действия.

Posted in CMMI, Стандарты и методологии | Отмечено: , , , , , | 2 комментария »

CMMI DEV v1.3 – Управление Конфигурацией

Posted by Шамрай Александр на Ноябрь 23, 2010

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

Процессная область Поддержки уровня зрелости 2

Назначение

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

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

Процесс управления конфигурацией включает в себя следующие мероприятия:

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

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

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

  • Аппаратное обеспечение и техника
  • Рисунки
  • Спецификации продукта
  • Конфигурации инструмента
  • Код и библиотеки
  • Компиляторы
  • Средства тестирования и тестовые сценарии
  • Журнал инсталляции
  • Файлы данных продукта
  • Технические публикации продукта
  • Планы
  • Пользовательские истории
  • Журнал итерации
  • Описание процесса
  • Требования
  • Архитектурная документация и дизайн
  • Планы линейки продукта, процессов и основные активы

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

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

Управление конфигурациями для рабочих продуктов может применяться на нескольких уровнях декомпозиции. Элементы конфигурации могут быть декомпозированы на компоненты конфигурации и единицы конфигурации. В этом процессе используется только один термин – «элемент конфигурации». Поэтому в этих практиках «элемент конфигурации» в некоторых случаях может интерпретироваться как «компонент конфигурации» или «единица конфигурации». (См. определение «элемент конфигурации» в глоссарии.)

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

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

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

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

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

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

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

В среде Agile, управление конфигурацией (УК) имеет важное значение в связи с необходимостью поддерживать частые изменения, частые сборки (как правило, ежедневные), несколько базовых линий и несколько рабочих пространств УК (например, для отдельных лиц, групп и даже для парного программирования). Agile команда может увязнуть, если организация не будет: 1) автоматизировать УК (например, скрипты сборки, учет состояния, проверку целостности) и 2) представлять УК как единый набор стандартных сервисов. В самом начале, команда Agile должна определить человека, который будет отвечать за обеспечение правильности реализации УК. В начале каждой итерации выполняется подтверждение целей УК. УК максимально интегрировано в ритмы каждой команды и сфокусировано на минимизацию отвлечения команды при выполнении работ. (См. «CMMI при использовании Agile подходов» в части I.)

Связанные процессы

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

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

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

  • СЦ 1 Установить Базовые Линии
    • СП 1.1 Идентифицируйте Элементы Конфигурации
    • СП 1.2 Установите Систему Управления Конфигурациями
    • СП 1.3 Создавайте или Выпускайте Базовые Линии
  • СЦ 2 Отслеживать и Контролировать Изменения
    • СП 2.1 Отслеживайте Изменения
    • СП 2.2 Контролируйте Элементы Конфигурации
  • СЦ 3 Установить Целостность
    • СЦ 3.1 Установите Записи Управления Конфигурацией
    • СЦ 3.2 Выполняйте Аудит Конфигурации

Специальные практики по целям

СЦ 1     Установить Базовые Линии

Базовые линии идентифицированных рабочих продуктов установлены

Практики установления базовых линий покрываются этой целью. Практики в рамках цели Отслеживать и Контролировать Изменения служат для поддержки базовых линий. Практики цели Установка Целостности описывают документирование и аудит целостности базовых линий.

СП 1.1 Идентифицируйте Элементы Конфигурации

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

Идентификация конфигурации это выбор и спецификация следующего:

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

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

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

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

1. Идентифицированные элементы конфигурации

Подпрактики

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

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

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

Примеры рабочие продуктов, которые могут быть частью элемента конфигурации:

  • Технический проект
  • Планы и процедуры тестирования
  • Результаты тестирования
  • Описание интерфейса
  • Рисунки
  • Исходный код
  • Пользовательские истории или карты историй
  • Задекларированные бизнес сценарии, бизнес логика или значение для бизнеса
  • Инструменты (например, компиляторы)
  • Описание процесса
  • Требования

2. Назначьте уникальные идентификаторы для элементов конфигурации.

3. Опишите важные характеристики каждого элемента конфигурации.

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

4. Опишите когда каждый элемент конфигурации был помещен под управление конфигурацией.

Пример критериев для определения, когда рабочий продукт может быть помещен под управление конфигурацией:

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

5. Определите владельца ответственного за каждый элемент конфигурации.

6. Укажите взаимосвязь между элементами конфигурации.

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

СП 1.2 Установите Систему Управления Конфигурациями

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

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

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

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

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

2. Процедуры контроля доступа системы управления конфигурацией

3. База данных запросов на изменение

Подпрактики

1. Установите механизмы для управления несколькими уровнями контроля.

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

Пример уровней управления:

  • Неконтролируемый: Кто угодно может внести изменения.
  • Рабочий процесс: Авторы контролируют изменения.
  • Контролируемый: Уполномоченный орган разрешает и контролирует изменения, и соответствующие заинтересованные стороны уведомляются, когда были внесены изменения.

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

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

3. Храните и извлекайте элементы конфигурации в системе управления конфигурацией.

4. Совместно используйте и передавайте элементы конфигурации между уровнями контроля в системе управления конфигурацией.

5. Храните и восстанавливайте предыдущие версии элементов конфигурации.

6. Храните, обновляйте и извлекайте записи управления конфигурацией.

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

8. Сохраняйте содержимое системы управления конфигурацией.

Примеры функций сохранения системы управления конфигурацией:

  • Резервное копирование и восстановление файлов управления конфигурацией
  • Архивирование файлов управления конфигурацией
  • Восстановление после ошибок управления конфигурацией

9. Пересматривайте структуру управления конфигурацией по мере необходимости.

СП 1.3 Создавайте или Выпускайте Базовые Линии

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

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

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

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

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

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

1. Базовые линии

2. Описание базовых линий

Подпрактики

1. Получите разрешение от ГКИ до создания или выпуска базовых линий элементов конфигурации.

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

3. Опишите набор элементов конфигурации, которые содержатся в базовой линии.

4. Сделайте текущий набор базовых линий легко доступным.

СЦ 2     Отслеживать и Контролировать Изменения

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

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

СП 2.1 Отслеживайте Изменения

Отслеживайте запросы на изменение для элементов конфигурации.

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

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

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

1. Запросы на изменение

Подпрактики

1. Инициируйте и записывайте запросы на изменение в базе данных запросов на изменение.

2. Анализируйте влияние изменений и исправлений, предложенных в запросах на изменение.

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

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

Изменения оцениваются на предмет их влияния на планы выпуска.

3. Устанавливайте категорию и приоритет запросов на изменение.

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

Изменения планируются для будущих базовых линий.

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

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

5. Отслеживайте статус запросов на изменение до закрытия.

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

СП 2.2 Контролируйте Элементы Конфигурации

Контролируйте изменение элементов конфигурации.

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

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

1. История изменений элементов конфигурации

2. Архивы базовых линий

Подпрактики

1. Контролируйте изменение элементов конфигурации на протяжении всего жизненного цикла продукта или услуги.

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

Например, разрешение может исходить от ГКИ, руководителя проекта, владельца продукта или клиента.

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

Примеры изъятия на редактирование и регистрации изменений:

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

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

5. Записывайте изменения в элементы конфигурации и причины этих изменений по мере необходимости.

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

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

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

СЦ 3Установить Целостность

Целостность базовых линий установлена и поддерживается.

Целостность базовых линий, установленная процессами в рамках целей Установить Базовые Линии, и поддерживаемая процессами в рамках целей Отслеживать и Контролировать Изменения, обеспечивается практиками в рамках этой цели.

СЦ 3.1 Установите Записи Управления Конфигурацией

Создавайте и поддерживайте записи описания элементов конфигурации.

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

1. История изменений элементов конфигурации

2. Журнал изменений

3. Записи запроса на изменение

4. Состояние элементов конфигурации

5. Различия между базовыми линиями

Подпрактики

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

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

Примеры мероприятий для определения доступа к информации о состоянии конфигурации:

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

3. Указывайте последнюю версию базовой линии.

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

5. Описывайте различия между последовательными базовыми линиями.

6. Изменяйте статус и историю (т. е. внесение изменения и другие действия) каждого элемента конфигурации по мере необходимости.

СЦ 3.2 Выполняйте Аудит Конфигурации

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

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

Примеры типов аудита:

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

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

1. Результаты аудита конфигурации

2. Последовательность действий

Подпрактики

1. Оценивайте целостность базовых линий.

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

3. Проверяйте структуру и целостность элементов в системе управления конфигурацией.

4. Подтвердите полноту, правильность и согласованность элементов в системе управления конфигурацией.

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

5. Подтвердите соответствие с применяемыми стандартами и процедурами управления конфигурацией.

6. Отслеживайте последовательность действий от аудита до закрытия.

Posted in CMMI, Стандарты и методологии | Отмечено: , , , , , | 2 комментария »

Записки мистера Томпкинса из романа об управлении проектами «Deadline»

Posted by Шамрай Александр на Август 17, 2010

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

Безопасность и перемены

  1. Если человек не чувствует, что находится в безопасности, он будет противиться переменам.
  2. Перемены необходимы руководителю для успешной работы (наверняка они необходимы и в любой другой деятельности).
  3. Неуверенность заставляет человека избегать риска.
  4. Избегая риска, человек упускает все новые возможности и выгоды, которые могли бы принести ему перемены.
  5. Человека легко запугать прямыми угрозами, но также можно просто дать ему понять, что при случае с ним могут обойтись грубо и жестоко. Эффект будет таким же.

Отрицательная мотивация

  1. Угрозы — самый неподходящий вид мотивации, если вас волнует производительность сотрудников.
  2. Чем бы вы ни угрожали, задача все равно не будет выполнена, если с самого начала вы отвели на ее выполнение слишком мало времени.
  3. Более того, если люди не справятся, вам придется выполнить свои обещания.

Части тела, необходимые для управления проектами

  1. Для руководства нужны сердце, нутро, душа и нюх
  2. Так что:
    • руководить надо сердцем;
    • чувствовать нутром;
    • вкладывать в команду и проект душу;
    • иметь нюх на всякую ерунду и бессмыслицу.

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

  1. Чтобы нанять человека на работу, менеджеру необходимы все его способности: сердце, душа, нюх и способность чувствовать нутром (по большей части последнее).
  2. Не пытайтесь нанимать людей в одиночку — гораздо лучше задействовать в этом процессе интуицию двух менеджеров.
  3. Попросите новых членов команды взяться в проекте за ту работу, которую им уже случалось успешно выполнять в прошлом, а прочие амбиции и рост отложить до следующего проекта.
  4. Попросите наводку — тот человек, которого вы выбрали себе в команду, наверняка может посоветовать, кого вам еще следует нанять.
  5. Больше слушайте, меньше говорите.
  6. И все это сработает еще лучше, если вы слегка подтасуете колоду.

Повышение производительности

  1. Не существует никаких краткосрочных мер, которые позволили бы быстро повысить производительность роботы.
  2. Повышение производительности — результат долгосрочных усилий.
  3. Любые средства для повышения производительности, которые обещают немедленный результат, на самом деле не что иное, как «птичье молоко» .

Управление рисками

  1. Чтобы управлять проектом, достаточно управлять его рисками.
  2. Создайте список рисков для каждого проекта.
  3. Отслеживайте те риски, которые являются причиной провала проекта, а не только конечные риски.
  4. Оцените вероятность возникновения и стоимость каждого риска.
  5. Для каждого риска определите показатель — симптом, по которому можно определить, что риск превращается в проблему.
  6. Назначьте специального человека для управления рисками, и пусть он не поддерживает девиз «Мы можем все!», который культивирует начальство.
  7. Создайте доступные (возможно, анонимные) каналы для сообщения плохих новостей руководству.

Играй в защите

  1. Сокращайте потери.
  2. Успех проекта можно скорее обеспечить сокращением ненужных усилий, чем стремлением к новым победам.
  3. Чем раньше вы прекратите ненужную работу, тем лучше для всего проекта.
  4. Не пытайтесь создавать новые команды без необходимости; поищите в коллективе уже сложившиеся и сработавшиеся команды.
  5. Оставляйте команды работать вместе и после окончания проекта (если они сами того хотят), чтобы у пришедших вам на смену руководителей было меньше проблем с плохо срабатывающимися командами.
  6. Считайте, что команда, которая хочет продолжать работать вместе и дальше, — это одна из основных целей любого проекта.
  7. День, который мы теряем в начале проекта, значит так же много, как и день, потерянный в конце.
  8. Есть тысяча и один способ потратить день зря и ни одного, чтобы вернуть этот день обратно.

Моделирование процесса разработки

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

Извращенная политика

  1. В любой момент нужно быть готовым отказаться от работы и попросить расчет…
  2. …однако это не означает, что тем самым вы сумеете избежать последствий извращенной политики.
  3. Извращенная политика достанет вас везде, даже в самой здоровой и чистой организации.
  4. Главный признак извращенной политики: во главу угла ставятся личные цели и влияние, а не общие интересы компании.
  5. Это может произойти даже тогда, когда личные цели напрямую противоречат целям организации.
  6. Один из побочных эффектов извращенной политики: иметь хорошо укомплектованную команду становится небезопасно.

Сбор метрических данных

  1. Определяйте размер каждого проекта.
  2. Не усердствуйте поначалу с выбором единицы измерения — если впоследствии вам предстоит работать с реальными данными, для начала сойдут и абстрактные единицы.
  3. Стройте сложные метрики на основе простых (тех, которые легко подсчитать в любом программном продукте).
  4. Собирайте архивные данные, чтобы считать производительность труда по уже законченным проектам.
  5. Работайте над формулами вычисления сложных синтетических метрик до тех пор, пока полученные результаты не будут наиболее точно отражать отношение абстрактных единиц к указанному в архивных данных объему работ.
  6. Проведите через всю архивную базу данных линию тренда, которая будет показывать ожидаемый объем работ в виде отношения значений сложных синтетических метрик.
  7. Теперь для каждого нового проекта достаточно будет высчитать значение синтетической метрики и использовать ее при определении ожидаемого объема работ.
  8. Не забывайте об «уровне помех» на линии производительности и используйте его, как индикатор при определении допустимых отклонений от общей траектории.

Процесс разработки и его улучшение

  1. Хороший процесс разработки и его постоянное улучшение — весьма достойные цели.
  2. Но существуют еще и рабочие цели и задачи: хороший работник сконцентрирует внимание как раз на них, даже если вы его об этом не просили.
  3. Формальные программы, направленные на улучшение существующего процессе разработки, будут дорого стоить команде — и во временном, и в денежном отношении. Даже отдельные усилия по улучшению процесса могут отбросить команду далеко назад. Что касается возможного повышения производительности, то даже если это и произойдет, то едва ли выгоды от этого повышения покроют затраты.
  4. Можно надеяться получить положительный результат от одного какого-нибудь хорошо взвешенного и тщательно выбранного усовершенствования в методике работы. В этом случае оно может покрыть деньги и время, потребовавшиеся на его внедрение.
  5. Попытка внедрить более одного усовершенствования методологии — гиблое дело. Программы, направленные на улучшение многих приемов и навыков (например, переход на следующий уровень СММ), скорее всего приведут к тому, что сроки только увеличатся.
  6. Опасность стандартизированного процесса разработки состоит в том, что за рутинными операциями люди могут не заметить возможность сэкономить время и усилия по разработке проекта.
  7. Что касается чрезмерно больших команд, то там стандартизированный процесс будет неукоснительно соблюдаться до тех пор, пока он позволяет всем чувствовать себя при деле (не важно, с пользой для проекта или нет).

Делать работу по-другому

  1. Есть только один способ сократить время на разработку, когда его и без того мало — уменьшить сроки отладки программы.
  2. Проекты с высокой производительностью требуют гораздо меньше времени на отладку и исправление ошибок.
  3. Проекты с высокой производительностью требуют гораздо больше времени на проектирование.
  4. Нельзя заставить людей делать что-то по-другому, если ты о них не заботишься, если ты ими не интересуешься. Чтобы они изменились, ты должен понимать (и ценить) их самих, что они делают и к чему стремятся.

Что дает давление сверху

  1. Люди не начнут быстрее соображать, если руководство будет давить на них.
  2. Чем больше сверхурочной работы, тем ниже производительность.
  3. Немного давления и сверхурочной работы могут помочь сконцентрироваться на проблеме, понять и почувствовать ее важность, но длительное давление всегда плохо.
  4. Возможно, руководство так любит применять давление, потому что просто не знает, как еще можно повлиять на ситуацию, или же потому, что альтернативные решения кажутся им слишком сложными.
  5. Ужасная догадка: давление и сверхурочная работа призваны решить только одну проблему — сохранить хорошую мину при плохой игре.

Сердитый начальник

  1. Злость и неуважение заразительны. Когда высшее руководство демонстрирует злость и неуважение к подчиненным, руководители среднего звена начинают копировать их поведение. Точно так же дети, которых наказывали в детстве, часто впоследствии становятся жестокими родителями.
  2. Неуважение и злоба, по мнению некоторых начальников, должны заставить подчиненных лучше работать. Это типичная политика «кнута и пряника». Но разве когда-нибудь неуважение со стороны начальства приводило к тому, что люди начинали лучше работать?
  3. Если начальник демонстрирует неуважение к подчиненным, это признак того, что он не может больше занимать свою должность (а вовсе не признак того, что у него плохие подчиненные).

Туманные спецификации

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

Конфликт

  1. Проект, в котором участвуют несколько сторон, обязательно столкнется с конфликтом интересов.
  2. Процесс создания и распространения программных систем — прямо таки рассадник всевозможных конфликтов.
  3. В большинстве компаний, где создается программное обеспечение, никто специально не занимается вопросом решения конфликтов.
  4. Конфликт заслуживает понимания и уважительного отношения. Конфликт не имеет ничего общего с непрофессиональным поведением.
  5. Донесите до каждого, что постараетесь учитывать интересы всех участников, и проследите, чтобы так оно и было.
  6. Тяжело договариваться. Гораздо легче выступать посредником.
  7. Объявите заранее, что если интересы конфликтующих сторон полностью или частично противоположны, то поиск решения будет переложен на посредника.
  8. Не забывайте: мы находимся по одну сторону баррикад. По другую сторону находится сама проблема.

Кто такой катализатор проекта

  1. Существуют люди катализаторы. Они помогают создать здоровую команду, отношения, боевой дух. Даже если бы они больше ничего не делали (а как правило, они делают куда как много), их роль в проекте остается одной из наиболее важных.
  2. Посредничество — еще одна сфера, в которой люди катализаторы просто незаменимы. Впрочем, посредничеству можно научиться, это не очень сложно.
  3. Первым шагом к посредничеству должна быть маленькая церемония. Например, можно произнести фразу: «Вы позволите мне попробовать помочь вам решить этот спор?»

Человеку свойственно ошибаться

  1. Нам кажется, что самое страшное — не знать чего то. На самом деле гораздо хуже быть уверенным, что знаешь, когда на самом деле это не так.

О персонале

  1. Если в самом начале проект делает большая команда, это снижает эффективность самой ответственной части работы — определения архитектуры системы (потому что всем разработчиком надо скорее дать какую то работу).
  2. Если работу раздать людям и командам еще до того, как завершится стадия дизайна продукта, не получится создать простые и эффективные модели взаимодействия между людьми и рабочими группами.
  3. Это приведет к потере независимости, увеличению числа собраний и совещаний, общему недовольству.
  4. В идеале было бы хорошо сначала набрать маленькую команду, которая создала бы продуманную архитектуру системы, а уже потом, на последнюю, шестую часть времени разработки в эту команду можно было бы добавить новый персонал (который работал бы непосредственно над кодированием).
  5. Ужасное предположение: кажется, те команды, перед которыми не ставят жестких сроков, заканчивают работу быстрее!

Проблемы социологии

  1. Собрания должны быть небольшими. Для этого нужно сделать так, чтобы люди не боялись пропускать ненужные им собрания. Самый простой способ — заранее опубликовать повестку дня, а потом всегда строго ее придерживаться.
  2. Каждому проекту нужна какая то церемония или ритуал.
  3. С помощью церемоний можно концентрировать внимание собравшихся на основных целях и задачах совещания: сократить состав рабочей группы, повысить качество программного кода и т. п.
  4. Защищайте людей от оскорблений и ругани Начальства.
  5. Запомните: в работе страх = гнев. Те руководители, которые любят кричать на своих подчиненных и всячески унижают и оскорбляют их, на самом деле просто чего то очень боятся.
  6. Наблюдение: если бы для всех проявление грубости и злости к подчиненным всегда значило бы, что начальник просто боится, то никто из начальников не стал бы так себя вести просто из страха, что его страх станет заметен! (Это, конечно, не решает проблем такого руководителя, но, по крайней мере, оберегает его подчиненных.)

О патологической политике (еще раз)

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

Злоба и скупость

  1. Злоба и скупость — вот формула, которую начинают применять в плохих компаниях те, кто несет ответственность за неудачи в бизнесе.
  2. Злоба и скупость прямо противоположны истинным целям любой хорошей компании — быть щедрыми и заботливыми по отношении к своим сотрудникам.
  3. Когда вы подмечаете в компании проявления злобы и скупости, знайте, их настоящая причина — страх и боязнь провала.

Основы здравого смысла

  1. У проекта должно быть два срока сдачи — запланированный и желаемый.
  2. Эти сроки должны быть разными.

Posted in Книги, Разное | Отмечено: , , , | Leave a Comment »

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

Posted by Шамрай Александр на Июль 27, 2010

Перевел очередное руководство проекта Visual Studio ALM Rangers «Visual Studio 2010 Team Foundation Server Requirements Management Guidance«, которое рассказывает о возможностях TFS 2010 для организации эффективного процесса управления требованиями. Изначально это руководство готовилось для реализации процесса на TFS 2010 Beta1, поэтому есть один момент, который будет отличаться для релизной версии TFS 2010. Этот момент заключается в использовании рабочего элемента Возможность (Feature): в TFS 2010 Beta1 это был отдельный рабочий элемент, а уже в окончательной редакции он является просто отдельным типом Возможность рабочего элемента Требование. Поэтому при реализации у себя в организации изложенных в этом руководстве практик, учтите этот момент.

Содержание руководства:

  1. Введение в Управление требованиями с использованием Team Foundation Server. Целью данного руководства является предоставление формализованного опыта Microsoft в виде рекомендованных процедур и процессов, конфигураций Visual Studio Team System и Team Foundation Server, а также развитие навыков по дисциплине Инженерия требований вашего жизненного цикла разработки ПО. Ввиду изменчивости и вопреки методик, используемых в индустрии, в этом руководстве эти задачи приведены тремя способами.
    • Общие Руководство по Разработке
    • Традиционная разработка
    • Гибкая разработка
  2. Планирование управления требованиями. План управления требованиями должен быть разработан для определения и механизмов контроля информации, которая будет собираться и использоваться для сбора метрик, отчетности и контроля изменений требований к продукту.
  3. Трассировка Требований. Трассировка, вероятно, наиболее важный аспект в инженерии требований, который обеспечивает подотчетность команды разработки. Кроме этого, она помогает:
    • Идентифицировать источник и важность требований
    • Управлять масштабом проекта
    • Управлять изменениями требований
    • Оценить воздействие на проект изменения требований или других элементов проекта
    • Оценить влияние провала тестирования требований (например, не пройденный тест может означать, что требование не выполнено)
    • Убедиться, что все требования к системе будут выполнены при реализации
    • Убедиться, что приложение делает то, для чего оно предназначено
    • Дать разработчику контекст требований для задачи
  4. Анализ и Декомпозиция. Анализ и Валидация выполняются для:
    • Установки рабочей концепции и сценариев (требования продукта – например, пользовательские цели и контекстные диаграммы; требования компонента продукта – например, технические ограничения и рабочая концепция)
    • Установки и поддержки определения необходимых функциональных возможностей (функциональная архитектура, диаграммы деятельности и сценарий использования, объектно-ориентированный анализ с идентифицированными сервисами)
    • Анализа требований (дефекность/изменчивость требований, изменения требований, технические критерии качества выполнения, оценка рисков)
    • Валидации требований со всесторонними методами (Отчет о методах анализа и результатах)
  5. Выявление требований. Этот документ описывает выявление требований на каждом из своих эволюционных уровней в рамках параметров двух различных методологий: традиционной разработки приложений и гибкой методологии. Visual Studio и Team Foundation Server обеспечивают общую технологию для двух типов методологий и служат для планирования, хранения, отслеживания и отчетности в хранилище для всех стадий выявления.
  6. Спецификация требований. Независимо от уровня иерархии при выявлении требований (бизнес, системные или реализация), существуют некоторые основные свойства Team Foundation Server 2010, которые необходимо понимать для определения требований и их проверки. Этот раздел рассказывает о документировании различных элементов требований в виде рабочих элементов и использовании других методов.
  7. Валидация требований. Валидация представляет собой процесс оценки, будет ли конечный продукт удовлетворять требованиям заказчика, и помогает удостовериться, что требования были правильно поняты. Такой подход к поставке в последнее время называют «Test-First Development» или «Requirements-Based Testing».
  8. Управление изменениями и утверждение требований. Управление изменениями требований и утверждение описывает, как участник процесса формально получает утверждение для новых требований или изменений/расширений существующих требований. Фокус в этом разделе будет сделан на описании действий процесса изменения требований, управления базовыми линиями требований и разрешения на продолжение работ по реализации требования. Также будет уделяться большое внимание к соблюдению промышленных стандартов таких, как CMMI и ITIL, соответствие отраслевым нормам такие, как FDA CFR-21, Часть 11 и закону Сарбейнса-Оксли.
  9. Анализ влияния. Анализ влияния выполняется для:
    • Оценки в рамках задач, которые обеспечивают соответствие изменений всем техническим и проектным требованиям
    • Оценки влияния изменений за пределами непосредственного проекта или контракта требований (изменения в элементах, использующихся в нескольких продуктах, может решить текущую проблему, но вызывать проблему в других приложениях)
    • Определение влияния, которое изменения будут иметь для рабочих продуктов, связанных рабочих продуктов, рабочих графиков и стоимости проекта
  10. Дополнительные интеграции. Различные производители программного обеспечения и партнеры Microsoft разработали интеграции с Visual Studio, которые предоставляют возможности не очень хорошо реализованные в Visual Studio Team Suite. В частности, они имеют встроенные возможности в следующих областях: выявление, спецификации, валидации и управления изменениями. Тут список некоторых из наиболее тесно интегрированных решений.
  11. Контрольные списки для разработки требований. Контрольные списки, которые помогают улучшить качество разрабатываемых требований.

Дополнительная информация:

  • Visual Studio TFS Branching Guide 2010 – руководство по ветвлению для Team Foundation Server 2010 разработанное сообществом VSTS Rangers. Это руководство основано на практике использования для Team Foundation Server различных моделей ветвления и слияния.
  • TFS 2008 Branching Guide 2.0 – руководство по ветвлению для Team Foundation Server 2008 разработанное сообществом VSTS Rangers. Это руководство основано на практике использования для Team Foundation Server различных моделей ветвления и слияния.

Posted in Microsoft, Requirements Management Guidance, Team Foundation Server, Visual Studio | Отмечено: , , , , , , , , , | 2 комментария »

Руководство по управлению требованиями VS TFS 2010 – Введение в Управление требованиями с использованием Team Foundation Server

Posted by Шамрай Александр на Июль 13, 2010

<<Содержание

Добро пожаловать в Руководство по управлению требованиями Team Foundation Server! На TechReady7 (внутренние технические встречи Microsoft) в июле 2008 года, практики проголосовали за проекты Visual Studio ALM Rangers, в которых, по их мнению, они больше всего нуждаются. Разработка требований была признана одним из двух самых важных. В этом документе будут рассмотрены люди, процессы и руководство по технологиям для Разработки требований с использованием Team Foundation Server.

Целью данного руководства является предоставление формализованного опыта Microsoft в виде рекомендованных процедур и процессов, конфигураций Visual Studio Team System и Team Foundation Server, а также развитие навыков по дисциплине Инженерия требований вашего жизненного цикла разработки ПО. Ввиду изменчивости и вопреки методик, используемых в индустрии, в этом руководстве эти задачи приведены тремя способами.

  • Общие Руководство по Разработке Требований – есть практики инженерии требований, которые реализуются, независимо от используемой методологии. Например, общее развитие представления бизнес уровня к функциональным возможностям, качеству обслуживания определено в любом случае, выполняет разработку организация по традиционному водопаду в соответствии со стандартами института инженеров по электротехнике и радиоэлектронике (IEEE) или выполняется экстремальное программирование с гибкими методами. Руководство приведено на концептуальном уровне, по возможности с использованием конкретных примеров на Visual Studio/Team Foundation Server.
  • Традиционная разработка – руководство будет приведено в основном в соответствии со стандартами IEEE по инженерии требований. В руководстве будут описаны конкретные указания по выявлению бизнес требований, спецификации, а также валидации спецификаций функциональных и технических требований.
  • Гибкая разработка – даже в рамках гибких методов есть несколько методологий, которые подчеркивают или выделяют различные практики в рамках этой темы. Руководство сосредоточено в основном на Scrum в качестве выбранной методологии и ссылается при необходимости на другие методологии.

Сценарий Разработки Требований

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

  • Бизнес-требования и их приемо-сдаточные испытания;
  • Функциональные требования и их тестовые сценарий;
  • Технические требования и их нефункциональные ограничения, качество обслуживания;
  • Разработка спецификации и их тесты компонентов архитектуры приложения;
  • Исходный код и его модульные тесты;
  • Документация пользователя.

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

Этот сценарий будет служить основой для описания на протяжении всего этого руководства, и мы будем на него ссылаться при описании альтернатив на основе Общей, Традиционной и Agile практик, используемых в Microsoft и в индустрии в целом. В каждом шаге сценариев, описанных ниже, указано в какой части руководство можно найти более детальную информацию о его поддержке в Visual Studio Team System и Team Foundation Server.

  1. Анализ Проблемы и Целей и определение Видения – бизнес-руководители спонсируют проект для решения некоторых бизнес-проблем и достижения бизнес-цели. Бизнес-аналитик будет выявлять их в качестве требований к продукту в виде набора возможностей или бизнес-требований. Мы можем хранить их в Team Foundation Server в виде рабочего элемента «Возможность».
    1. Первоначально выявление будет направлено на бизнес-руководителей. После того, как возможности продукта будут выявлены, специалисты по бизнес-областям будут дополнять этот набор функций. (Разделы Планирование управления требованиями и Выявление)
    2. Валидация на этом уровне будет проверять не только точность описанных функции, но и определять их влияние на решение проблем бизнеса и достижения бизнес-целей. (Раздел Валидация требований)
    3. Проблемы и цели, как правило, хранятся в виде документа бизнес-сценарий, где, в нормальной ИТ организации спонсируемой CIO, менеджер проекта собирает предварительную смету расходов на решение этой проблемы в проекте разработки и выполняет анализ экономических выгод. Этот вид деятельности находится вне области инженерии требований этого руководства. Анализа экономического обоснования и дальнейшего выявление спонсоров и экспертов в этой области приводит к бизнес-требованиям или возможностям продукта, которые будут определены в документах по проекту; обычно в документе Спецификация бизнес требований. (Разделы Планирование управления требованиями и Спецификация требований)
  2. Переход к функциям – выполняя анализ возможностей, аналитик получает функциональную контекстную модель или диаграмму вариантов использования для всех функциональных сценариев, реализующих функции. Мы можем хранить их в качестве рабочего элемента «Пользовательское описание функциональности» (MSF для Agile) или «Требование» с типом «Функциональное» (MSF для CMMI) и связать их с каждой возможностью, которую они реализуют.
    1. Планирование требований – описано в разделе Планирование управления требованиями
    2. Аналитик анализирует возможности и готовится к выявлению функциональных требований пользователей заинтересованных сторон и бизнес экспертов по конкретным областям. Их анализ поможет им выявить правильные функциональные требования, задокументировать и выполнить их валидацию на точность. (Разделы Выявление, Анализ и Валидация требований)
    3. Полученные функциональные требования и возможности связываются – описано в разделе Трассировка требований
  3. Переход к качеству обслуживания и нефункциональным требованиям – проводится дальнейший анализ возможностей и функциональных требований. Аналитик, работая с другими составляющими продукта (инфраструктура, операции, архитектура и администраторы баз данных, удобство использования, эксперты по безопасности, управление и обеспечение соблюдения требований и т.д.), определяет нефункциональные требования и качества обслуживания. Опять же, мы можем хранить их в качестве рабочих элементов в Team Foundation Server и привязать их к каждой возможности или функции, из которых они получены.
    1. Анализ функциональных требований для получения качества обслуживания и нефункциональные требований – разделы Выявление, Анализ и Спецификация требований
    2. Валидация свойств и нефункциональных требований на точность (Раздел Валидация требований)
    3. Полученные требования и функциональные требования связываются – описано в разделе Трассировка требований
  4. Планирование работ – менеджер проекта определяет с командой разработчиков задачи разработки (будь то гибкий проект или водопад или что-нибудь между ними, задачи определяются и по-прежнему с оценкой трудозатрат определенным образом) на функциональные и нефункциональные требования. Их можно хранить как рабочие элементы «Задача» и связывать с функциональными или нефункциональным требованиям, для которых они были запланированы.
    1. Планирование разработки и тестирования – описано в разделе Анализ
  5. Разработка Приложения и Тестов — команда разработчиков может разрабатывать код проекта приложения и модульные тесты (и тесты производительности) и связать их с исходным кодом. Во время регистрации (check-in) изменений, они связывают их с задачей, и мы можем даже заставить их это делать.
    1. Наборы изменений (Change Sets) связываются с задачами и требованиями – описано в разделе Трассировка требований
  6. Проверка качества приложения — Мы выполняем модульные тесты, и мы с помощью отчета, который связан со сборкой, можем продемонстрировать, какие наборы изменений вошли в эту сборку и какие рабочие элементы были связаны с этими зарегистрированными наборами изменений. И мы можем это сделать с помощью Team Foundation Server. Мы выполняем Ручные или Web функциональные тесты, а также можно использовать общие тесты, которые доступны из внешних систем функционального тестирования (например, Quick Test Professional) и опубликовать результаты. Отчеты будут демонстрировать, что рабочие элементы покрыты всеми видами тестов, с использованием Team Foundation Server Data warehouse.
    1. Выполнить тесты, публиковать результаты, сгенерировать отчеты покрытия – описано в разделе Трассировка требований
  7. Планирование тестирования – почему планирование тестирования включено в темы инжиниринга требования? Что ж, планирование тестирования гарантирует, что валидация имеет место. Влидация предусматривает проверку, которая позволяет убедиться, что команда проекта понимает цели требований и может достичь согласования с источником требования (бизнес-спонсором или заинтересованным лицом). Проверка предусматривает тесты, которые команда предоставила и согласовала для поставки. Планирование тестирования обеспечивает хранилище и трассируемость всех работ, связанных с управлением тестирования. Таким образом, после шага (1), но до шага (2), мы теперь имеем надежный механизм для планирования приемо-сдаточных тестов для функциональных требований. На самом деле, планирование тестирования на каждом уровне может быть выполнено с помощью Visual Studio 2010 Test and Lab Manager edition. Таким образом, мы можем создать несколько тестовых планов и тестовых наборов в Test and Lab Manager, которые обеспечивают разработку устойчивого отчета плана тестирования, который показывает, какие тесты не были запланированы, какие были запланированы, но не реализованы, какие были реализованы, но не выполняются, какие были выполнены, но провалены и какие были выполнены и прошли. Все эти данные есть, а у нас теперь есть возможность получить такой отчет и сортировать результаты по рабочим элементам, к которым они принадлежат.
    1. Планирование тестирования для системных требований — описано в разделах Трассировка требований, Валидация требований и Спецификация требований

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

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

Отступление

В 20-тилетней карьере лидера в области разработки, практик, внедрения передового опыта, обучения, коучинга по управлению жизненным циклом разработки для своих клиентов, мы установили, что Инженерия требования, как правило, наиболее сложная дисциплина в рамках программного обеспечения и сообществ разработки систем. Таким образом, это руководство было разработано с подходом, который напрашивается на критику и изменение. Команда из более 20 практиков из Microsoft Consulting Services, Product Management и программы MVP собрались вместе для обсуждения и определения предложения руководства, которое учитывает передовые практики индустрии и лучшие практики Microsoft в дисциплине разработки требований.

Visual Studio ALM Rangers

Эта руководство было разработано в проекте Visual Studio ALM Ranger. Visual Studio ALM Rangers особая группа в составе представителей Visual Studio Product group и Microsoft Services. Их миссия заключается в предоставлении решений для отсутствующих возможностей или руководств.

Целевая аудитория этого руководства это Microsoft пользователи Team Foundation Server «уровня 200-300». Целевая группа рассматривается как промежуточная к опытным пользователям Team Foundation Server, глубоко понимающим возможности продукта в реальном мире. Части этого руководства могут быть полезными для новичков и экспертов Team Foundation Server, но пользователи этих уровней не фокусируются во внимание этого руководства.

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

Мы надеемся, что данное руководство охватывает более 80% нужд сегмента инженерии требований. В дополнение к этому руководство вы найдете отдельные методологические сценарии, Q&A, учебные пособия и обновление трассировки и документацию по стратегии. Мы призываем участников нашего сообщества предоставлять идеи для новых сценариев, которые мы будем добавлять в пакеты. Эти новые пакеты будут доступны на CodePlex или MSDN и будут обновлены на основе отзывов пользователей.

Словарь

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

Термин Определение
Анализ требований

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

Активный дизайн (Participatory Design)

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

Аппаратное требование

Требование, которым должно соответствовать аппаратное обеспечение.

Артефакт (рабочий продукт)

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

Атрибуты

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

Базовая линия

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

Базовая линия требований

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

Бизнес-правила

Правила и ограничения, регулирующие отдельные бизнес-процессы и работы.

Валидация требований

Валидация фокусирует внимание на определении, работает ли продукт как ожидалось. Валидация требований предусматривает проверку связи между тестами (и результаты тестов) и тестируемой системой. Удовлетворяет ли построенная система требованиям?

Вариант использования

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

Взаимодействие

Атрибут: возможность взаимодействия одной программной системы с другой.

Гибкость

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

Группа контроля за изменениями

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

Группа пользователей

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

Двунаправленная трассировка

Ассоциации между двумя или более логических объектов, которая видна в любом направлении (т. е. в и от сущности). (См. также Трассировка требований).

Дефектное требование

Требование, которое является неправильным, неоднозначным, непроверяемым, нетрассируемым, неполным и/или противоречивым.

Диаграммы взаимодействия

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

Доступность

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

Жизненный цикл разработки программного обеспечения

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

Заинтересованное лицо

Лицо, которое будет затронуто продуктом и имеет прямое или косвенное влияние на требования к продукту.

Интервью

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

Контекстно-независимые вопросы

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

Коробочное решение

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

Корректность

Атрибут: соответствие стандартам и техническим условиям.

Круг пользователей

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

Мета-вопрос

Вопрос о вопросах. Обычно используется в интервью, чтобы определить или собеседник понимает цель собеседования. Пример мета-вопроса: Мои вопросы актуальны? Понятны ли Вам мои вопросы? Ваши ответы официальны?

Моделирование требований

Работы, направленные на превращение набора требований в графическое и/или текстовое представление модели системы, как она будет работать, если требования были выполнены.

Надежность

Атрибут: работа без сбоев в течение определенного периода времени.

Нетехнические ограничения

Требования, связанные с продуктом, поставкой и выпуском (например, стоимость и сроки).

Однозначное требование

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

Повторное использование

Атрибут: возможность переработки для использования в другом приложении.

Покупатель

Тот, кто приобретает продукт для пользователей.

Пользователь

Тот, кто будет использовать продукт.

Пользовательские требования

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

Портативность

Атрибут: возможность перемещения для использования в другой среде.

Представитель пользователей

Один человек, который представляет пользователей для разработчиков продукта.

Приемочные тесты

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

Приоритетность требований

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

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

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

Прототип

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

Разработка программного продукта

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

Разработка требований

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

Раскадровка

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

Сбор требований

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

Сессия совместного дизайна приложения (Joint Application Design (JAD))

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

Сценарий

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

Системные требования

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

Спецификация требований

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

Спонсор

Лицо, которое выполняет финансирование этого проекта.

Тестируемость

Атрибут: возможность проверить (протестировать) указанную операцию и производительность.

Тестируемое требование

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

Техника Фокус-группы

Техникой сбора требований, которая следует сценарию, и организована из набора вопросов для интервью с группой людей. Группа состоит из 3 — 10 пользователей, экспертов или клиентов, нескольких разработчиков или маркетологов.

Технические ограничения

Характеристики среды продукта, которые влияют на выполнение и/или дизайн продукта.

Техническая рецензия

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

Техническое требование

Свойства продукта для условий, в которых разрабатывается продукт.

Трассировка требования

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

Трассируемое требование

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

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

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

Требование к системным интерфейсам

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

Удобство использования

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

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

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

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

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

Функциональное требование

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

Целостность

Атрибут: (использование) безотказная работа при несанкционированном доступе; (данные) сохранение содержания и порядка данных и артефактов.

Эффективность

Атрибутов: относительное использование ресурсов (памяти, времени, пропускной способности сети).

Эксплуатационная надежность

Атрибут: простота обнаружения и исправления неисправности в период времени (во время использования).

Unified Modeling Language (UML)

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

<<Содержание

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

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

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

<<Содержание

В 1992 году было опубликовано следующее высказывание, на 17 лет раньше, чем Visual Studio ALM Ranger начали разрабатывать руководство по инжинирингу требований:

1«Многие из проблем в создании и поддержке системы можно связать с проблемами выявления. Тем не менее, большая часть исследований, проводимых по инженерии требований, игнорируют выявление, руководитель Лейте (автор) заявил, ссылаясь на обследование анализа требований в 1987, что состояние дел в области анализа требований не сильно отличается от того, что было в конце 1970-х. Он утверждает, что исследования в этой области сконцентрированы на точность, представление, методы моделирования, верификации и утверждения, а не на улучшение выявления потребностей. Он приходит к выводу, что ‘усилия исследований должны быть направлены на методы и инструменты, необходимые для улучшения процесса анализа требований, и, в частности, на те, которые оказывают большую поддержку выявлению требований'».

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

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

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

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

Общие темы выявления

Планирование выявления

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

Планирование выявления обеспечивается 3-мя основными уровнями: ранний сбор информации, представление требований и анализ, валидация.

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

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

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

Планирование выявления включает в себя последовательные мероприятия в начале проекта, а затем, через уточнение, будет включать мероприятия для дальнейшего анализа и проверки:

  • Выявление всех соответствующих сторон, которые являются источниками требований.
    Эта и следующая работа направлены на определение «Персонажей» приложения. Один из ключевых элементов Microsoft Solution Framework (MSF). Участник может быть конечным пользователем, интерфейсом системы или фактором среды. Несмотря на то, какие роли определены в любой нетипичной организации, ниже приведен типовой список возможных ролей:
    • Бизнес – человек или люди, обеспечивающие финансирование проекта
    • Пользователь – человек или люди, которые в конечном итоге будут использовать систему
    • Администратор – тоже, что и  пользователь, но особенность в том, что он обеспечивает безопасность, потоки данных, а также новых пользователей, продукты, цены и другую информацию в приложениях.
    • Инфраструктура – IT организация, которая обеспечивает оборудование и информационную поддержку на площадке, где приложение будет установлено. С точки зрения независимых поставщиков или сайта хостинговой компании, например SalesForce.Com, это люди, которые должны определить производительность оборудования и требования к пропускной способности для поддержки конечных пользователей, которые будут использовать приложения, размещенные на сайтах SalesForce.Com.
    • Операционная поддержка — люди или группа, которые будут оказывать операционную поддержку конечных пользователей. Они поддерживают аппаратное и программное обеспечение в рабочем состоянии в течение всего периода использования. Они также представляют службу поддержки пользователей, которые периодически сталкиваются с дефектами или отключениями.
  • Определение профиля соответствующих сторон, для которых требования будут собираться.
    Это включает в себя определение трудозатрат, необходимых для работы с ними, чтобы получить требования и риски для этих требований точно и однозначно. Например, типичный конечный пользователь в страховой организации будет описывать свои потребности в рамках непосредственно своего рабочего места. Снимки экрана для них предоставляются на бумаге и, когда они готовы (в редких случаях пользователь беспокоится, как это происходит), только тогда они могут подтвердить, что это было сделано правильно. Если сравнить с Директором информационной службы, который дает бюджет для проекта разработки приложения, предназначенного для повышения эффективности процессов страховых выплат, то их потребности описываются низкой стоимостью реализации, повышения производительности труда в денежном выражении и экономии времени, а также в утверждениях, которые приводят к увеличению прибыли.
  • Определение методов выявления (следующий раздел).
    Соответствующая техника выявления для каждого профиля будет зависеть от рабочего графика, ограничения времени, ограничения глубины знаний, возможной точности и других факторов. Использование этих факторов позволит выделить задачи с оценкой трудозатрат по выявлению требований для каждого источника.

Чтобы планировать эти три этапа, можно использовать электронную таблицу или план работ MS Project и синхронизировать с рабочим элементом TFS Задача. Следующие шаги демонстрируют, как сделать это с помощью MS Project:

  • Откройте MS Project и установите правильные атрибуты соответствия, выбрав TFS Team Project из пункта меню «Team»:

  • Далее выберите сервер TFS и коллекцию проектов по умолчанию, для которых будут планироваться задачи по выявлению:

  • Далее введите задачи выявления с оценками, основанными на анализе каждого человека, который представляет собой персонаж для вашего приложения:

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

  • Вот как это выглядит в TFS после публикации:

Методы выявления

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

Семинары по выявлению

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

Семинары по требованиям не нуждаются в поддержке Visual Studio/TFS, но их результаты могут покрываться этой технологией.

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

Другие примеры внешних источников для требований:

  • Постановка работы
  • Запрос на предложение
  • Миссия
  • Постановка задачи
  • Бизнес-правила
  • Законы и нормативные акты
  • Юридические системы
  • Бизнес-модели

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

Семинар по требованиям является одним из наиболее эффективных экономически и по времени средств в смысле получения обратной связи. Такая же концепция применяется в сессиях JAD (Joint Application Development) или RAD (Rapid Application Development) . Вот некоторые из преимуществ семинара:

  • Ускорение процесса выявления
  • Сбор всех заинтересованных сторон на интенсивную, сосредоточенную встречу
  • Содействие обеспечению направленности и прогресса
  • Все мнения будут выслушаны
  • Результаты доступны немедленно
  • Обеспечение основы для применения других методов выявления
Механизм семинара

Как правило, для крупных проектов семинар может длиться от 3-х до 5-ти рабочих дней. Ниже показан высокий уровень выполнения семинара по требованиям.

  • Предварительное планирование семинара – перед семинаром бизнес-аналитик должен будет подготовить все материалы, выявить все заинтересованные стороны, послать приглашение участникам, подготовить темы для повестки дня,  правила и направление действий для семинара. Вот перечень мероприятий, которые должны быть выполнены:
    • Предложение семинара – некоторые заинтересованные стороны не хотят идти на семинар по различным причинам. Нужно подготовить пункты с выгодами для каждой из заинтересованных сторон, которые учитывают их потребности.
    • Создание команды – выявление всех заинтересованных сторон и посредников. Подготовка окон в их расписании для семинара.
    • Определение логистики – зарезервировать конференц-залы и комнаты для перерывов. Планирование заказов блюд, напитков и легких закусок. Убедитесь, что доступны Интернет, проекторы, доски, стикеры, маркеры и т.д.
    • Отправка материалов предварительного чтения и предпосылочных материалов – заинтересованные стороны должны иметь всю имеющуюся информацию, а также время для её рассмотрения. Отправьте их с четкой инструкцией о том, как подготовиться к семинару.
    • Подготовка повестки дня – используйте расписание (обычно с шагом в полдня, разделенным на 2-а перерыва по 15 минут в течение каждой сессии), сформируйте повестку дня для каждого из семинаров. Например, в результате оценки ALM, мы создали семинар, состоящий из:
      • Введение -> Понедельник: 8:00-12:00 – Введение для всех заинтересованных сторон, их ролей, а также открытое обсуждение желаемых целей семинара.
      • Сессия 1 – Дисциплина инженерии требований -> Понедельник: 1:00-5:00 – 30 минут введение в проблемы инженерии требований, выявленных в ходе оценки, 1 час дискуссии с использованием причинно-следственных диаграмм, 15-30 минут присвоение приоритетов проблемам, 1 час мозговой штурм по решению, 15-30 минут выставление приоритетов и сведение результатов.
      • Сессия 2 – Дисциплина управления изменениями и конфигурациями -> Вторник: 8:00-12:00 – тот же формат, что и для сессии 1
      • Сессия 3 – Управление и мониторинг Agile-проекта и Дисциплина контроля -> Вторник: 1:00-5:00 – Формат скорее как обсуждение «Моделирование вариантов использования». Описать все сценарии команды Agile, определить роли, определить действия, определить рабочие продукты; больше описание процесса, которому будут следовать, и мозговой штурм на проблемных областях
      • Сессия 4 – Дисциплина повторного использования Программного обеспечения / Архитектура -> Среда: 8:00-12:00, так же как сессия 1
      • Закрытие -> Среда: 1:00-3:00 – Подведение итогов каждой сессии, определение предстоящей работы и описание последующих действий.
  • Сессии семинаров – выполнение семинара, согласно некоторым из основ:
    • Содействие – вы или кто-то вами определенный поддерживает темп сессий. Этот человек не будет вводить свое мнение, но будет привносить предложения, если сессия становится нудной, чтобы вернуть ее в нужное русло.
    • Поддержание темпа – также, как предыдущий пункт.
    • Запись выводов – организатору может быть сложно документировать результаты каждой сессии. Рассмотрите вопрос о найме специального человека (писателя) для этой цели. Очень важно, чтоб все понимали, что информация должна быть учтена и документирована. Это не простая задача.
    • Краткие выводы – в конце каждой сессии, работа с заинтересованными сторонами с целью обобщения каких-либо выводов или решений, которые были сделаны. Убедитесь, что все участники сессии поняли все варианты, которые были представлены, и все необходимые действия были предприняты в отношении результатов.
  • Выпуск результатов – найдите время для подведения итогов, их анализа и организации.
    • Обобщить выводы – организуйте результаты в формате, который можно проанализировать.
    • Объединить информацию – после проведения анализа, консолидируйте информацию таким образом, чтоб она могла быть представлена заинтересованным сторонам для последующих действий.
  • Передача
    • Представить результаты для заказчика
    • Определить следующие шаги и действия для реализации окончательного набора требований.

Мозговой штурм

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

«Мозговой штурм означает проведение с группой короткого промежутка времени, скажем, 15 минут, когда всем в комнате разрешено говорить все, что они считают важным для проекта. После этого организатор переключает группу на организацию и выставление приоритетов для результатов» 3.

Техника мозгового штурма

  • Начните с четкой установки цели мозгового штурма.
  • Сгенерируйте такое количество идей, насколько это возможно.
  • Не ограничивайте ваше воображение.
  • Не допускайте критики или обсуждения на время сбора информации.
  • После сбора информации комбинируйте и объединяйте идеи.

Для генерации идей есть несколько полезных для использования методов:

  • Стикеры и маркеры — каждый участник получает маркер и комплект стикеров. Они могут свободно записать такое количество идей, насколько это возможно для них, и прикрепить их к стенке. Роль организатора состоит в том, чтобы прочитать каждую заметку и объединить их как можно лучше по тематическим областям. После истечения срока, скажем, 15 минут, остановите сбор идей и затем попросите остальных участников помочь в распределении стикеров на стене. Это самый быстрый способ получить собранную и организованную информацию.
  • Белая доска или мольберт — либо каждый участник поднимает руку, и организатор записывает их идеи на мольберт или доску, либо каждый участник получает маркер, и они  по очереди пишут на доске до окончания срока. Этим методом сложно организовать информацию после выполнения сбора.

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

Другие методы уменьшения количества найденных идей:

  • Дайте каждому возможность проголосовать.
  • Пусть каждый определит приоритеты каждой идеи по категориям (например, критическая, важно и неплохо, если будет), которые имеют свой вес (например, 3, 2, 1). Суммы из приоритетов для каждой идеи скажут вам её важность по отношению к другим.
  • Дайте каждому участнику 100$ для голосования (нереальных денег), и пусть они покупают свои идеи за необходимую, по их мнению, стоимость. Это позволит не только выявить наиболее популярные идеи, но и определит приоритеты для всех идеи, которые были сгенерированы.

Документация по результатам

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

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

Интервью

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

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

Контекстно-свободные вопросы:

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

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

Общий процесс для проведения интервью:

  1. Предварительное обследование среды заинтересованных сторон или пользователей и компании.
  2. Рассмотрение вопросов до интервью и подготовка ожидаемых ответов на некоторые вопросы для того, чтобы вникнуть в проблему за проблемой.
  3. Следите за форматом во время интервью для того, чтобы задавались правильные вопросы.
  4. Подведите итоги по двум или трем проблемам в конце интервью.
  5. Повторите, что вы узнали, чтобы подтвердить ваше понимание.

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

  1. Задайте вопрос
  2. Прослушайте ответ
  3. Повторите ответ, чтобы удостовериться, что вы услышали правильно
  4. Повторите ответ своими словами, чтобы показать, что вы поняли, что вы слышали.

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

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

Не готовьте вопросник, который имеет столько вопросов, что будет трудно наладить контакт. Если вы хорошо работаете с интервью, у вас будет хорошее понимание предметной области и её проблем. После этого можно задокументировать результаты в шаблон, который может быть использован для формирования требований в качестве рабочих элементов в TFS.

Примеры контекстно-свободных вопросов используемых для поиска пользователей и интерфейсов системы:

  • Кто является заказчиком?
  • Кто является пользователем?
  • Они имеют различные потребности?
  • Каковы их особенности, возможности, условия работы?

Примеры контекстно-свободные вопросы, которые помогут вам понять бизнес-процессы:

  • В чем заключается проблема?
  • Что является основанием для желающих решения этой проблемы?
  • Существуют ли другие причины для стремления решить эту проблему?
  • Какая польза успешного решения?
  • Как можно решить проблему?
  • Какой компромисс между временем и пользой?
  • Как еще можно обеспечить решение этой проблемы?

Примеры контекстно-свободных вопросов, которые помогут вам понять требования к системе или разрабатываемому продукту:

  • Какую проблему решает этот продукт?
  • Какие бизнес-задачи может создать этот продукт?
  • Какие опасности могут существовать для пользователей?
  • В какой среде продукт будет работать?
  • Каковы ваши ожидания по удобству использования?
  • Каковы ваши ожидания по надежности?
  • Какая производительность/точность требуется?

Примеры контекстно-свободных мета-вопросов:

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

Пример не контекстно-свободных вопросов, которых следует избегать:

  • Наводящие вопросы: «Вы хотите большой экран, не так ли?»
  • Вопросы с ответом: «Если будет 50 пунктов, так будет нормально?
  • Контрольные высказывания: «Можем ли мы вернуться к моим вопросам?»
  • Слишком длинные и слишком сложные: «Этот вопрос из трех частей …»

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

  • Не просить людей описать вещи, которые они обычно не описывают.
  • Не задавайте вопросы предполагающие, что пользователи могут описать различные комплексные задачи. Пример: методы завязывания ваших шнурков.
  • В целом, люди могут делать многие вещи, которые они не могут описать.
  • Эмпирические данные – плохое соотношение.
  • Спрашивайте открытые вопросы.
  • Избегайте вопросов, которые начинаются с «почему?», поскольку такие вопросы могут вызвать оборонительную реакцию.

При проведении сессии интервью помните:

  • Не ждите простых ответов.
  • Не торопите собеседника.
  • Слушайте, слушайте, слушайте!

Документация по результатам собеседования

Общий Шаблон Интервью, показанный в конце этого документа в приложении, является хорошей начальной точкой для подготовки интервью. Полученные результаты могут быть описаны в шаблоне и храниться в документе Резюме Интервью на папке Требования TFS Team Project:

Диаграммы причинно-следственных связей (Fishbone Diagrams)

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

Схема диаграммы причинно-следственных связей может быть описана так же, как кости рыб, после того, как мясо было съедено. «Голова» и «позвоночник» рыбы представляют собой описание исходной задачи. Каждая «кость» от основы является причиной или главной причиной этой проблемы. Первоначальный набор «хребта» затем анализируется на важность и актуальность этой проблемы. Главные 20% из причин потом анализируются по своим собственным диаграммам «рыбным скелетам» пока проблемы не будет достаточно проанализированы.

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

Разработка раскадровки, каркасов и прототипов

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

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

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

Как документировать раскадровку

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

Вот несколько примеров:

  • Бумага эскизы или рисунки
  • Растровые инструменты рисования
  • Индекс карты
  • PowerPoint слайды
  • Скриншоты (если пользовательский интерфейс или прототип пользовательского интерфейса существует)

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

Несколько слов о каркасах и прототипах

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

Примеры возможных форматов:

  • Проект Expression Blend SketchFlow
  • Горизонтальные прототипы, написанные с использованием решений Web,WPF и Windows Forms
  • PowerPoint слайды с дополнительной анимацией или логикой навигации

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

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

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

Переход от раскадровки к рабочим элементам

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

Рисунок 1. Соответствие частей раскадровки рабочим элементам

Более комплексный способ объединения прототипов и рабочих элементов является документирование сценариев использования в Visual Studio Architect Edition и создание прототипов с использованием Expression Blend SketchFlow. Диаграммы вариантов использования содержат визуальное описание того, как пользователи взаимодействуют с программным обеспечением, а также могут включать ссылки на другие артефакты внутри вашего решения Visual Studio. Эти так называемые элементы Артефакты могут использоваться для подключения информации к диаграмме, например, для справки. Это то, где SketchFlow начинает действовать.

SketchFlow, который входит в состав Expression Blend 3, представляет собой инструмент для создания экранных прототипов для приложений WPF и Silverlight. Решения, созданные с SketchFlow, могут быть открыты и отредактированы в Visual Studio и наоборот. На рисунке 2 показано решение Visual Studio, которое содержит проект модели с диаграммой варианта использования и проект SketchFlow под названием «UsecasesTestScreens». Последний был создан раньше в Expression Blend SketchFlow.

Рисунок 2. Проекты SketchFlow могут быть импортированы в Visual Studio

После открытия проекта SketchFlow в Visual Studio и создания диаграмм вариантов использования в решении, можно просто перетащить экраны, выполненные в SketchFlow, в диаграммы вариантов использования. Файлы, перемещенные в диаграмму, будут автоматически преобразованы в элемент артефакт и использоваться, как и любой другой элемент внутри диаграммы варианта использования (см. Рисунок 3).

Рисунок 3. Перемещение экрана пользовательского интерфейса на диаграмме варианта использования преобразует ее в артефакт

При двойном нажатии на артефакт-снимок откроется связанный Xaml-файл с выбранным вами средством просмотра XML, например, Internet Explorer. Таким образом, можно непосредственно связать диаграммы варианта использования с UI, предоставляя разработчикам возможность лучше понять проект и одновременного включения идей дизайнеров пользовательского интерфейса.

Наблюдение

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

Результатом наблюдения может быть диаграмма бизнес-активностей или последовательность шагов, представляющих рабочие процедуры (сценарии использования). Эта документация должна храниться в библиотеке требований документации TFS для использования в ходе анализа для выявления наиболее значимых функциональных требований. Смотрите раздел «Анализ и Декомпозиция» для более конкретных рекомендаций.

Рецензирование существующих требований

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

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

Механизмы формального рецензирования требований:

  1. Распространение документации, которая должна быть рассмотрена, каждому из заинтересованных лиц для проверки.
  2. Попросите каждого участника рассмотреть документ с их точки зрения и документировать или выделить любые вопросы, дополнительные или упущенные требования или ограничения относительно возможности осуществления этого требования. Их точка зрения определяется той ролью, которую они выполняют, то есть инженер испытаний должен иметь возможность определить тесты для требований в документации. Архитектор инфраструктуры должен сопоставить новые функциональные возможности своей производительности для гарантированной поддержки больших приложений на оборудование предприятия или DBA необходимо определить, есть ли какая-либо информация, которая приведет к требованиям увеличения хранилищ для корпоративных баз данных.
  3. Используйте контрольные списки для проверки каждого документа на покрытие каждой точки зрения. Смотрите раздел руководства «Валидация требований«.
  4. После предоставления заинтересованным сторонам времени для самостоятельного рецензирования, соберите их вместе для обсуждения своих выводов. Это даст им возможность проверить свои выводы со всеми участниками, а также возможность выявить недостающие требования.
  5. Результаты анализа должны быть отмечены в качестве рабочих элементов либо требования, либо запроса на изменение или задачи для дальнейшего анализа или утверждения.

Тема выявления в Agile

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

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

  1. Создание журнала продукта – для гибких команд (Scrum), журнал продукта представляет собой все требования, которые должны быть разработаны командой разработчиков. Владелец продукта несет ответственность за создание этого списка. Он может использовать многие из описанных выше методов для руководства в формировании списка. Однако основное различие заключается в том, что он обычно не обеспечивает формальности для этого. Планирование рассчитывается на очень короткий период времени, и вся группа заинтересованных лиц рассматривается в качестве однородной группы источников для различных требований, которые поставляются в журнал продукта. Качество журнала не столь высокое, как в традиционных проектах. Это не является ни риском, ни недостатком, потому что гибкая команда вновь будет пересматривать его с владельцем продукта и другими заинтересованными сторонами, чтобы углубиться в детали, когда придет время.
    Журнал продукта должен храниться в TFS как рабочие элементы «Требование», «Сценарий» или «Качество обслуживания».
  2. Анализ Журнала итераций – как только «кусок» журнала продукта утвержден в качестве цели для итерации, члены команды разработчиков будут использовать в основном техники интервью и неофициальных раскадровок для конкретизации деталей пользовательского описания функциональности, опираясь на владельца продукта или его делегата для предоставления детализации. Документация используется по минимуму. Этого достаточно, чтобы позволить членам команды разработать и сопоставить поведение требований к архитектуре предприятия/приложения, написать свои тесты и код и выполнить приемо-сдаточные испытания для них.
    Для хранения элемент журнала, как правило, представляется в виде рабочего элемента «Требование» в шаблоне процесса MSF для CMMI , или «Сценарий» шаблона процесса MSF для Agile.

Руководство по выявлению для традиционной разработки

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

В TFS, шаблон процесса MSF для CMMI обеспечивает поддержку для управления требованиями и разработку требований, которые компания может использовать для организации их в соответствии модели качества CMMI уровня 3. В рамках этого руководства шаблона процесса Microsoft определил «персонажи», которые могут быть использованы для определения пользователей, которые помогут выявить функциональные требования.

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

Дополнительные комментарии по традиционному выявлению

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

Для того чтобы обеспечить такую поддержку, используются следующие правила:

  1. Если вы собираетесь получить требования от заинтересованных сторон:
    1. Планируйте работы и используйте рабочие элементы «Задача» для оценки и отслеживания работ выявления.
    2. Разработайте и применяйте контрольные списки к конкретным областям и работам по выявлению, которые должны быть выполнены. Храните шаблон контрольного списка в TFS в шаблонах требований библиотеки документации.
    3. Измените название шаблона, заполните его, добавьте свою контактную информацию и дату, когда он использовался, а затем сохраните результат в библиотеке документации артефактов Требований в TFS.
    4. Связывайте любые результирующие рабочие элементы с артефактами в библиотеке документации.
  2. Если вы выявляете требования из ранее сформированной документации:
    1. Планируйте работы и используйте рабочие элементы «Задача» для оценки и отслеживания работ выявления.
    2. Разработайте и применяйте контрольные списки к конкретным областям и работам по выявлению, которые должны быть выполнены. Храните шаблон контрольного списка в TFS в шаблонах требований библиотеки документации.
    3. Измените название шаблона, заполните его, добавьте свою контактную информацию и дату, когда он использовался, а затем сохраните результат в библиотеке документации артефактов Требований в TFS.
    4. Связывайте любые результирующие рабочие элементы с артефактами в библиотеке документации.
  3. Если по итогам интервью, «мозгового штурма» или другой сессии в рамках семинара по требованиям:
    1. Планируйте работы и используйте рабочие элементы «Задача» для оценки и отслеживания работ выявления.
    2. Разработайте и применяйте контрольные списки и шаблоны для документирования результатов работы. Храните их в шаблонах документации библиотеки TFS Team Project.
    3. Заполните шаблон, измените его название, добавьте имена и роли всех участников, а также добавьте даты события в документ перед его сохранением в библиотеке документации артефактов требований в TFS Team Project.
    4. Связывайте любые результирующие рабочие элементы с артефактами в библиотеке документации.
  4. Если вы создаете больше, чем просто рабочий элемент для представления набора требований:
    1. Разработайте и используйте шаблон, который доступен для всей организации (хранится в шаблонах библиотеки документации TFS Team Project)
    2. Храните итоговые документы, таблицы, графики и т.д. в библиотеке документации требований TFS Team Project
    3. Связывайте результирующий файл с соответствующими рабочими элементами через URL ссылки в TFS.

1 — ChrKang92, p. 4 — Christel, M. G., & Kang, K. C. (1992). Issues in Requirements Elicitation. Pittsburgh, PA: Software Engineering Institute.
2 — SEI 91, p.26 — Software Engineering Institute. (1991). Requirements Engineering and Analysis Workshop Proceedings, Technical Report. Software Engineering Institute Requirements Engineering Project. Pittsburgh, PA: Software Engineering Institute.
3 — Rat99 — Rational Software Corporation. (1999). Guideline: Brainstorming and Idea Reduction. The Rational Unified Process . Rational Software Corporation.

<<Содержание

Posted in Microsoft, Requirements Management Guidance, Team Foundation Server, Visual Studio | Отмечено: , , , , , , , , , | 2 комментария »

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