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

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

Posts Tagged ‘development’

CMMI DEV v1.3 – Управление Организационными Показателями

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

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

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

Назначение

Назначением Управление Организационными Показателями (ОУП) является активный контроль эффективности деятельности Организации для удовлетворения своих бизнес-целей.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • СЦ 1 Управлять Бизнес Показателями
    • СП 1.1 Поддерживайте Бизнес Цели
    • СП 1.2 Анализируйте Данные Показателей Процессов
    • СП 1.3 Выявляйте Потенциальные Области для Улучшения
  • СЦ 2 Выбрать Улучшения
    • СП 2.1 Выявляйте Предложения по Улучшению
    • СП 2.2 Анализируйте Предложения по Улучшению
    • СП 2.3 Выполняйте Валидацию Улучшений
    • СП 2.4 Выбирайте и Реализуйте Улучшения для Внедрения
  • СЦ 3 Внедрить Улучшения
    • Планируйте Внедрение
    • Управляйте Внедрением
    • Оценивайте Эффекты от Улучшений

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

СЦ 1 Управлять Бизнес Показателями

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

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

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

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

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

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

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

СП 1.1 Поддерживайте Бизнес Цели

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

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

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

1. Пересмотренные бизнес-цели

2. Пересмотренные цели качества и показателей процессов

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

4. Информирование о всех пересмотренных целях

5. Обновленные меры показателей процесса

Подпрактики

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

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

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

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

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

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

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

4. Поддерживайте цели качества и показателей процесса для обеспечения изменений в бизнес-целей.

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

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

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

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

СП 1.2 Анализируйте Данные Показателей Процесса

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

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

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

1. Анализ текущих возможностей на основе бизнес-целей

2. Недостатки показателей процесса

3. Риски, связанные с достижением бизнес целей

Подпрактики

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

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

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

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

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

СП 1.3 Выявляйте Потенциальные Области для Улучшения

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

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

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

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

1. Потенциальные области для улучшения

Подпрактики

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

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

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

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

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

СЦ 2 Выбрать Улучшения

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

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

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

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

СП 2.1 Выявляйте улучшения

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

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

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

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

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

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

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

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

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

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

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

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

1. Предлагаемые инкрементальные улучшения

2. Предлагаемые инновационные улучшения

Подпрактики

1. Выявляйте предлагаемые улучшения.

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

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

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

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

 

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

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

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

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

СП 2.2 Анализируйте Предложения по Улучшению

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

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

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

1. Предлагаемые предложения по улучшению

2. Отобранные улучшения для проверки

Подпрактики

1. Анализируйте затраты и выгоды предлагаемых улучшений.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

8. Документируйте результаты процесса отбора.

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

  • Распоряжение для каждого предложения по улучшению
  • Обоснование распоряжения для каждого предложения по улучшению

СП 2.3 Выполняйте Валидацию Улучшений

Выполняйте валидацию выбранных улучшений.

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

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

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

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

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

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

1. План валидации

2. Отчеты для оценки валидации

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

Подпрактики

1. Планируйте валидацию.

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

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

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

3. Проконсультируйтесь и получите поддержку от тех, кто выполняет проверку.

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

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

6. Отслеживание ход валидации на основе их планов.

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

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

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

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

СП 2.4 Выбирайте и Реализуйте Улучшения для Внедрения

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

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

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

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

1. Улучшения, выбранные для внедрения

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

Подпрактики

1. Устанавливайте приоритеты для внедрения.

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

2. Выбирайте улучшения для внедрения.

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

3. Определяйте, как внедрять каждое улучшение.

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

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

4. Документируйте результаты процесса отбора.

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

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

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

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

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

6. Обновляйте активы организационного процесса.

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

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

СЦ 3 Внедрить Улучшения

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

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

СП 3.1 Запланируйте внедрение

Устанавливайте и поддерживайте планы внедрения выбранных улучшений.

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

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

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

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

1.Планы внедрений для выбранных улучшений

Подпрактики

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

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

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

3. Определите целевой набор проектов для внедрения улучшения.

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

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

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

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

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

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

5. Документируйте планы внедрения выбранных улучшений.

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

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

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

7. Пересматривайте планы по внедрению выбранных улучшений по мере необходимости.

СП 3.2 Управляйте Внедрением

Управляйте внедрением выбранных улучшений.

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

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

1. Обновленные учебные материалы (с учетом внедренных улучшений)

2. Документально подтвержденные результаты мероприятий внедрения улучшения

3. Пересмотренные меры улучшений, цели, приоритеты и планы внедрения

Подпрактики

1. Отслеживайте внедрение улучшений с помощью планов внедрения.

2. Координируйте внедрение улучшений во всей организации.

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

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

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

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

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

4. Координируйте внедрение улучшений в процессы определенных для проектов в соответствующих случаях.

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

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

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

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

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

8. Задокументируйте и оцените результаты внедрения улучшений.

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

  • Выявление и документирование накопленного опыта
  • Пересмотр мер улучшений, целей, приоритетов и планов развертывания

СП 3.3 Оценивайте Эффекты от Улучшения

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

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

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

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

1. Документально подтвержденные меры эффектов, вызванные внедренными улучшениями

Подпрактики

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

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

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

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

CMMI DEV v1.3 – Показатели Организационных Процессов

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

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

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

Назначение

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

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

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

  • Установка организационных количественных целей показателей качества и выполнения процесса на основе бизнес-целей (см. определение «цели показателей качества и выполнения процесса» в глоссарии.)
  • Выбор процессов или подпроцессов для анализа показателей выполнения процесса.
  • Создание определения мер, которые будут использоваться для анализа показателей выполнения процесса (см. определение «показатели выполнения процесса» в глоссарии).
  • Установление базовых показателей выполнения процесса и моделей выполнения процесса (см. определения «базовые показатели выполнения процесса» и «модели показателей выполнения процесса» в глоссарии).

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

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

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

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

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

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

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

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

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

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

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

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

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

  • СЦ 1 Установить Базовые Показатели и Модели Выполнения
    • СП 1.1 Устанавливайте Цели для Показателей Качества и Выполнения Процесса
    • СП 1.2 Выберите Процессы
    • СП 1.3 Установите Меры для Показателей Выполнения Процесса
    • СП 1.4 Анализируйте Показатели Выполнения Процесса и Устанавливайте Базовые Показатели Выполнения Процесса
    • СП 1.5 Устанавливайте Модели Показателей Выполнения Процесса

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

СЦ 1 Установить Базовые Показатели и Модели Выполнения

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

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

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

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

СП 1.1 Устанавливайте Цели для Показателей Качества и Выполнения Процесса

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

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

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

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

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

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

Подпрактики

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

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

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

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

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

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

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

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

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

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

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

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

СП 1.2 Выберите Процессы

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

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

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

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

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

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

Подпрактики

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

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

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

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

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

  • Причинно-следственный анализ
  • Анализ чувствительности

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

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

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

  • Связи подпроцессов с целями качества и показателями выполнения процесса
  • Связи подпроцессов с бизнес-целями
  • Последовательность целей (например, отношение Больших Y к Важным X, стратегическое Хосин планирование)
  • Система сбалансированных показателей
  • Развертывание Качественных Функций (Quality function deployment (QFD))
  • Цель Вопрос Метрика
  • Документация для модели показателей выполнения процесса

4. Пересматривайте выбор по мере необходимости.

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

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

СП 1.3 Установите Меры для Показателей Выполнения Процесса

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

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

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

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

Подпрактики

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

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

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

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

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

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

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

3. Включайте выбранные меры в организационный набор общих мер.

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

4. Пересматривайте набор мер в случае необходимости.

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

СП 1.4 Анализируйте Показатели Выполнения Процесса и Устанавливайте Базовые Показатели Выполнения Процесса

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

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

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

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

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

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

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

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

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

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

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

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

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

Подпрактики

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Когда изменились процессы
  • Когда организационные результаты изменились
  • Когда организационные потребности изменились
  • Когда процессы поставщиков изменились
  • Когда поставщики изменились

СП 1.5 Устанакливайте Модели Показателей Выполнения Процесса

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

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

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

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

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

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

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

  • Модели динамики системы
  • Регрессионные модели
  • Модели сложности
  • Дискретно-событийное моделирование
  • Модели Монте-Карло

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

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

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

Подпрактики

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

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

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

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

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

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

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

Posted in CMMI, Стандарты и методологии | Отмечено: , , , , , , , | 1 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 Шамрай Александр на Октябрь 3, 2011

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

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

Назначение

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

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

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

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

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

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

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

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

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

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

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

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

  • СЦ 1 Определить Возможности Совершенствования Процессов
    • СП 1.1 Устанавливайте Потребности Организационных Процессов
    • СП 1.2 Проведите Экспертизу Процессов Организации
    • СП 1.3 Идентифицируйте Совершенствования Процессов Организации
  • СЦ 2 Запланировать и Выполнить Мероприятий по Процессу
    • СП 2.1 Разрабатывайте Планы Мероприятий по Процессу
    • СП 2.2 Выполняйте План Мероприятий по Процессу
  • СЦ 3 Внедрить Активы Организационных Процессов и Включить Полученный Опыт
    • СП 3.1 Внедряйте Активы Организационных Процессов
    • СП 3.2 Внедряйте Стандартные Процессы
    • СП 3.3 Выполняйте Мониторинг Реализации
    • СП 3.4 Включайте Полученный Опыт в Активы Организационных Процессов

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

СЦ 1 Определить Возможности Совершенствования Процессов

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

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

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

СП 1.1 Устанавливайте Потребности Организационных Процессов

Устанавливайте и поддерживайте описание потребностей и целей процессов для организации.

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

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

  • Характеристики процессов
  • Цели выполнения процесса, такие как время выхода на рынок и поставляемое качество
  • Эффективность процесса

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

1. Потребности и цели процессов организации

Подпрактики

1. Идентифицируйте политики, стандарты и бизнес-цели, которые применимы к процессам организации.

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

  • ISO/IEC 12207:2008 Systems and Software Engineering – Software Life Cycle Processes [ISO 2008a]
  • ISO/IEC 15288:2008 Systems and Software Engineering – System Life Cycle Processes [ISO 2008b]
  • ISO/IEC 27001:2005 Information technology – Security techniques – Information Security Management Systems – Requirements [ISO/IEC 2005]
  • ISO/IEC 14764:2006 Software Engineering – Software Life Cycle Processes – Maintenance [ISO 2006b]
  • ISO/IEC 20000 Information Technology – Service Management [ISO 2005b]
  • Assurance Focus for CMMI [DHS 2009]
  • NDIA Engineering for System Assurance Guidebook [NDIA 2008]
  • Resiliency Management Model [SEI 2010c]

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

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

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

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

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

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

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

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

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

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

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

  • Уровень детализации
  • Нотация процесса
  • Гранулярность

5. Документируйте потребности и цели процессов организации.

6. Пересматривайте потребности и цели процессов организации по мере необходимости.

СП 1.2 Проводите Экспертизу Процессов Организации

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

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

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

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

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

1. Планы экспертизы процессов организации

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

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

Подпрактики

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

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

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

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

Границы экспертизы процессов затрагивают следующие:

  • Определение организации (например, сайты, бизнес-области), которые будут покрыты экспертизой
  • Идентификация функций проекта и поддержки, которые будут представлять организацию при экспертизе
  • Процессы для экспертизы

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

Экспертиза процессов может выполняться во многих формах. Они должны учитывать потребности и цели организации, которые могут со временем меняться. Например, экспертиза может быть основана на модели процессов, таких как модель CMMI, или на национальных или международных стандартах, таких как ISO 9001 [ISO 2008c]. Экспертиза может быть также основана на сравнительном тесте с другими организациями, в которых выявлены практики, которые могут способствовать повышению эффективности работы организации. Характеристики методов экспертизы могут варьироваться в зависимости от времени и трудозатрат, состава экспертной комиссии и метода и глубины исследования.

4. Планируйте, готовьте календарный график и готовьтесь к экспертизе процессов.

5. Проводите экспертизу процессов.

6. Документируйте и поставляйте результаты и мероприятия по экспертизе.

СП 1.3 Идентифицируйте Усовершенствования для Процессов Организации

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

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

1. Анализ кандидатов на совершенствование процессов

2. Идентификация усовершенствований для процессов организации

Подпрактики

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

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

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

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

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

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

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

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

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

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

СЦ 2 Запланировать и Провести Мероприятия по Процессу

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

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

СП 2.1 Устанавливайте План Мероприятий по Процессу

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

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

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

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

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

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

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

Подпрактики

1. Определяйте стратегии, подходы и мероприятия для выявленных совершенствований процесса.

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

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

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

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

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

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

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

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

СП 2.2 Выполняйте Планы Мероприятий по Процессу

Выполняйте планы мероприятий по процессу.

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

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

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

3. Планы для пилотной эксплуатации

Подпрактики

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

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

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

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

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

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

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

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

СЦ 3 Внедрить Активы Организационных Процессов и Включить Полученный Опыт

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

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

СП 3.1 Внедряйте Организационные Активы Процессов

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

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

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

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

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

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

3. Документация об изменениях в организационных активах процессов

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

Подпрактики

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

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

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

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

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

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

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

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

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

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

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

СП 3.2 Внедряйте Стандартные Процессы

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

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

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

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

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

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

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

3. Протоколы адаптации и реализации набора стандартных процессов организации

Подпрактики

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

2. Идентифицируйте активные проекты, которые выиграют от реализации текущего набора стандартных процессов организации.

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

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

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

5. Ведите протоколы адаптации и реализации процессов для идентификации проектов.

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

Аудит соответствия процессов объективно оценивает мероприятия в проекте в отношении к определенному процессу проекта.

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

СП 3.3 Выполняйте Мониторинг Реализации

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

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

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

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

2. Состояние и результаты аудита соответствия процессов

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

Подпрактики

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

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

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

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

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

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

СП 3.4 Включайте Полученный Опыт в Активы Организационных Процессов

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

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

1. Предложения по усовершенствованию процессов

2. Полученные уроки по процессам

3. Измерения организационных активов процессов

4. Рекомендации по совершенствованию организационных активов процессов

5. Протоколы мероприятий по совершенствованию процессов организации

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

Подпрактики

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

8. Управляйте предложениями по усовершенствованию процессов.

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

Мероприятия по управлению предложениями совершенствования процессов, как правило, включают следующее:

  • Запрос предложений по совершенствованию процессов
  • Сбор предложений по совершенствованию процессов
  • Рассмотрение предложений по совершенствованию процессов
  • Выбор предложений по совершенствованию процесса, которые должны быть реализованы
  • Отслеживание реализации предложений по совершенствованию процессов

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

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

9. Создавайте и ведите протоколы по мероприятиям совершенствования процессов организации.

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

CMMI DEV v1.3 – Определение Организационных Процессов

Posted by Шамрай Александр на Сентябрь 26, 2011

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

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

Назначение

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

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

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

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

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

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

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

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

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

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

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

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

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

  • СЦ 1 Установить Организационные Активы Процессов
    • СП 1.1 Устанавливайте Стандартные Процессы
    • СП 1.2 Устанавливайте Описания Модели Жизненного Цикла
    • СП 1.3 Устанавливайте Критерии и Руководства по Адаптации
    • СП 1.4 Устанавливайте Хранилище Измерений Организации
    • СП 1.5 Устанавливайте Библиотеку Активов Процесса Организации
    • СП 1.6 Устанавливайте Стандарты Рабочей Среды
    • СП 1.7 Устанавливайте Правила и Руководства для Команд

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

СЦ 1 Установить Организационные Активы Процессов

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

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

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

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

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

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

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

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

1. Набор стандартных процессов организации

Подпрактики

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

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

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

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

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

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

  • Роли процесса
  • Применение стандартов
  • Применение процедур, методов, инструментов и ресурсов
  • Цели выполнения процесса
  • Критерии входа
  • Входные элементы
  • Точки верификации (например, коллегиальные оценки)
  • Выходные элементы
  • Интерфейсы
  • Критерии выхода
  • Меры продукта и процесса

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

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

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

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

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

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

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

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

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

7. Документируйте набор стандартных процессов организации.

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

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

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

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

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

СП 1.2 Устанавливайте Описания Модели Жизненного Цикла

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

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

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

1. Описания моделей жизненного цикла

Подпрактики

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

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

  • Водопадная или Последовательная
  • Спиральная
  • Эволюционная
  • Инкрементальная
  • Итерационная

2. Документируйте описания моделей жизненного цикла.

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

3. Проводите коллегиальные оценки моделей жизненного цикла.

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

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

СП 1.3 Устанавливайте Критерии и Руководства по Адаптации

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

Критерии и руководства по адаптации описывают следующее:

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

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

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

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

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

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

Критерии и руководства адаптации могут позволять использование стандартного процесса «как он есть» без какой-либо адаптации.

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

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

Подпрактики

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

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

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

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

  • Изменение модели жизненного цикла
  • Сочетание элементов различных моделей жизненного цикла
  • Изменение элементов процесса
  • Замена элементов процесса
  • Изменение порядка элементов процесса

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

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

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

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

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

6. Пересматривайте руководства по адаптации по мере необходимости.

СП 1.4 Устанавливайте Хранилище Измерений Организации

Устанавливайте и поддерживайте хранилище измерений организации.

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

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

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

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

2. Проектирование хранилища измерений организации

3. Хранилище измерений организации (например, структура хранилища, среды поддержки)

4. Данные измерений организации

Подпрактики

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

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

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

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

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

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

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

3. Разрабатывайте и внедряйте хранилище измерений.

Функции хранилища измерений включают следующее:

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

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

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

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

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

6. Вводите указанные меры в хранилище.

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

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

8. Пересматривайте хранилище измерений, общий набор мер и процедур при изменении потребностей организации.

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

  • Добавляются новые процессы
  • Процессы пересмотрены и необходимы новые меры
  • Требуется более подробная детализация данных
  • Требуется повышение прозрачности процесса
  • Меры удаляются

СП 1.5 Устанавливайте Библиотеку Активов Процессов Организации

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

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

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

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

1. Проектирование библиотеки активов процессов организации

2. Библиотека активов процессов организации

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

4. Каталог элементов в библиотеке активов процессов организации

Подпрактики

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

2. Указывайте критерии для включения элементов в библиотеку.

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

3. Указывайте правила хранения, обновления и получения элементов.

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

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

6. Периодически пересматривайте использование каждого элемента.

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

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

  • Добавляются новые элементы
  • Элементы удаляются
  • Изменились текущие версии элементов

СП 1.6 Устанавливайте Стандарты Рабочей Среды

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

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

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

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

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

1. Стандарты рабочей среды

Подпрактики

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

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

СП 1.7 Устанавливайте Правила и Руководства для Команд

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

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

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

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

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

1. Правила и руководства для структурирования и формирования команд

2. Операционные правила для команд

Подпрактики

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

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

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

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

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

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

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

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

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

CMMI DEV v1.3 – Организационное Обучение

Posted by Шамрай Александр на Сентябрь 19, 2011

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

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

Назначение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

СЦ 1 Установить Возможности для Организационного Обучения

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

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

СП 1.1 Устанавливайте Стратегические Потребности в Обучении

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

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

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

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

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

1. Потребности в обучении

2. Оценочный анализ

Подпрактики

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

2. Документируйте стратегические потребности обучения в организации.

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

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

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

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

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

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

СП 1.2 Определяйте Какие Потребности в Обучении в Ответственности Организации

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

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

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

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

1. Общие потребности обучения для проектов и групп поддержки

2. Обязательства по обучению

Подпрактики

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

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

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

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

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

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

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

СП 1.3 Устанавливайте Тактический План Обучения Организации

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

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

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

1. Тактический план обучения организации

Подпрактики

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

Тактические планы обучения организации обычно содержат следующее:

  • Потребности в обучении
  • Темы обучения
  • Расписания на основе учебной деятельности и их зависимостей
  • Методы, используемые для обучения
  • Требования и стандарты качества учебных материалов
  • Задачи обучения, роли и обязанности
  • Требуемые ресурсы, включая инструменты, оборудование, персонал, навыки и знания

2. Устанавливайте обязательства выполнения к плану.

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

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

СП 1.4 Устанавливайте Возможности для Обучении

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

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

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

1. Материалы обучения и артефакты поддержки

Подпрактики

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

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

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

  • Обучение в классах
  • Компьютерное обучение
  • Руководства для самостоятельного обучения
  • Формальное ученичество и наставничество
  • Обучающее видео
  • Обучение с помощью доски и мела
  • Семинары во время обеда
  • Структурированное по месту в работе обучение

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

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

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

  • Применение в целях выполнения работы или процесса
  • Наличие времени подготовки для реализации проекта
  • Применимость к бизнес-целям
  • Наличие собственных специалистов
  • Наличие внешних источников обучения

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

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

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

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

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

  • Курсы
  • Компьютерное обучение
  • Видео

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

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

5. Описывайте обучение в программе обучения организации.

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

  • Темы, затрагиваемые в обучении
  • Целевая аудитория
  • Предварительные требования и подготовка для участия
  • Цели обучения
  • Длительность обучение
  • Планы занятий
  • Критерии завершения курса
  • Критерии для предоставления отказа от обучения

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

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

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

СЦ 2 Обеспечить Обучение

Обучение отдельных лиц для эффективного выполнения их ролей обеспечено.

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

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

СП 2.1 Проводите Обучение

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

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

1. Проведенные обучающие курсы

Подпрактики

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

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

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

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

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

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

3. Проводите обучение.

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

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

СП 2.2 Устанавливайте Протоколы Обучения

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

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

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

1. Протоколы обучения

2. Обновления обучений в хранилище организации

Подпрактики

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

2. Ведите учет всех сотрудников, которые отказались от обучения.

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

3. Ведите учет всех студентов, успешно окончивших их необходимое обучение.

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

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

СП 2.3 Оценивайте Эффективность Обучения

Оценивайте эффективность программ организационного обучения.

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

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

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

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

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

1. Оценка эффективности обучения

2. Оценки выполнения программы обучения

3. Форма оценки инструктора

4. Экзамены по обучению

Подпрактики

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

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

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

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

CMMI DEV v1.3 – Интеграция Продукта

Posted by Шамрай Александр на Сентябрь 16, 2011

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

Инженерная процессная область уровня зрелости 3

Назначение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

СЦ 1 Подготовиться к Интеграции Продукта

Проведена подготовка к интеграции продукта.

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

СП 1.1 Устанавливайте Стратегию Интеграции

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

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

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

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

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

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

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

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

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

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

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

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

1. Стратегия интеграции продукта

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

Подпрактики

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

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

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

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

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

4. Выберите лучшую стратегию интеграции.

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

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

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

6. Записывайте обоснование принимаемых решений и задержек.

СП 1.2 Устанавливайте Среду Интеграции Продукта

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

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

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

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

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

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

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

Подпрактики

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

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

3. Решите, следует ли сделать или купить необходимую среду для интеграции продукта.

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

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

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

5. Поддерживайте среду интеграции продукта на протяжении всего проекта.

6. Утилизируйте те части среды, которые больше бесполезны.

СП 1.3 Устанавливайте Процедуры и Критерии Интеграции Продукта

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

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

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

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

  • Уровень тестирования сборки компонентов
  • Верификация интерфейсов
  • Пороговые значения отклонения производительности
  • Производные требования для сборки и ее внешних интерфейсов
  • Допустимые замены компонентов
  • Тестирование параметров среды
  • Ограничения на стоимость тестирования
  • Компромиссы для качества/стоимости операций интеграции
  • Вероятность правильного функционирования
  • Скорость доставки и ее вариации
  • Время от заказа до поставки
  • Наличие персонала
  • Наличие средств/линии/среды интеграции

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

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

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

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

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

1. Процедуры интеграции продукта

2. Критерии интеграции продукта

Подпрактики

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

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

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

СЦ 2 Проверить Совместимость Интерфейсов

Интерфейсы компонентов продукта и внутренние и внешние совместимы.

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

СП 2.1 Оценивайте Полноту Описания Интерфейсов

Оценивайте описания интерфейсов на покрытие и полноту.

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

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

1. Категории интерфейсов

2. Список интерфейсов в каждой категории

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

Подпрактики

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

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

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

  • Механические интерфейсы (например, вес и размер, центр тяжести, чистота деталей в эксплуатации, пространство, необходимое для обслуживания, стационарные связи, мобильные связи, удары и вибрации, полученные от несущей конструкции)
  • Шумовые интерфейсы (например, шум передаваемый структурой, шум передаваемый по воздуху, акустика)
  • Климатические интерфейсы (например, температура, влажность, давление, соленость)
  • Тепловые интерфейсы (например, тепло, теплопередача несущей конструкции, характеристики кондиционирования)
  • Жидкостные интерфейсы (например, пресная вода на входе/выходе, морская вода на входе/выходе для морских/прибрежных продуктов, кондиционирование воздуха, сжатый воздух, азот, топливо, смазочные масла, отработавшие газы)
  • Электрические интерфейсы (например, потребляемая мощность сети с переходными и пиковыми значениями; нечувствительный управляющей сигнал для питания и связи; чувствительный сигнал [например, аналоговые связи]; нарушающий сигнал [например, микроволны]; сигнал заземления для соблюдения стандарта TEMPEST)
  • Электромагнитные интерфейсы (например, магнитное поле, радио- и радиолокационные связи, руководства по длине оптических волн, коаксиальные и оптические кабеля)
  • Человеко-машинные интерфейсы (например, аудио синтез или синтез речи, распознавание аудио или голоса, дисплей [аналоговый циферблат, жидкокристаллический дисплей, светодиодные индикаторы], ручное управление [педаль, джойстик, трекбол, клавиатура, кнопки, сенсорный экран])
  • Интерфейсы сообщений (например, происхождение, место назначения, стимул, протоколы, характеристики данных)

2. Убедитесь, что компоненты продукта и интерфейсы выделены для обеспечения простого и правильного соединения для объединения компонентов продукта.

3. Периодически пересматривайте адекватность описания интерфейсов.

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

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

СП 2.2 Управляйте Интерфейсами

Управляйте внутренними и внешними описаниями интерфейсов, проектированием и изменениями для продукта или компонента продукта.

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

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

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

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

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

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

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

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

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

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

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

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

3. Список для согласования интерфейсов, определенных для каждой пары компонентов продукта, когда это возможно

4. Отчеты встречи рабочей группы управления интерфейсами

5. Задачи для обновления интерфейсов

6. Программный интерфейс приложения (API)

7. Обновленное описание или соглашение по интерфейсу

Подпрактики

1. Проверяйте совместимость интерфейсов на протяжении всей жизни продукта.

2. Решайте конфликты, несоответствия и проблемы изменений.

3. Поддерживайте хранилище для данных по интерфейсам доступным для участников проекта.

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

СЦ 3 Собрать Компоненты Продукта и Поставить Продукт

Верифицированные компоненты продукта собраны и интегрированные, верифицированные и валидированные продукты поставлены.

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

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

СП 3.1 Подтверждайте Готовность Компонентов Продукта к Интеграции

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

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

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

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

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

1. Приемочные документы на полученные компоненты продукта

2. Акты о поставке

3. Проверенные упаковочные списки

4. Отчеты по исключениям

5. Отказные листы

Подпрактики

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

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

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

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

5. Проверяйте состояние конфигурации в отношении ожидаемой конфигурации.

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

СП 3.2 Соберите Компоненты Продукта

Соберите компоненты продукта в соответствии со стратегией интеграции продукта и процедурам.

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

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

1. Собранный продукт или компоненты продукта

Подпрактики

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

2. Проводите интеграцию в соответствии со стратегией интеграции продукта, процедурам и критериям.

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

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

СП 3.3 Оценивайте Собранные Компоненты Продукта

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

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

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

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

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

1. Отчеты по исключениям

2. Отчеты оценки интерфейсов

3. Итоговые отчеты интеграции продукта

Подпрактики

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

2. Записывайте результаты оценки.

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

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

СП 3.4 Упаковывайте и Поставьте Продукт или Компонент Продукта

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

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

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

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

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

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

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

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 Шамрай Александр на Июль 25, 2011

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

Инженерная процессная область уровня зрелости 3

Назначение

Назначением Верификации (ВЕР) является проверка того, что выбранные рабочие продукты удовлетворяют их указанным требованиям.

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

Процессная область Верификация включает в себя следующее: подготовка верификации, выполнение верификации, а также определение корректирующих действий.

Верификация включает в себя верификацию продукта и промежуточных рабочих продуктов на соответствие всем выбранным требованиям, включая требования заказчиков, требования к продукту и компонентам продукта. Для линейки продуктов, основные активы и связанные с ними механизмы вариации линейки продукта также должны быть верифицированы. В этой процессной области, где используются термины «продукт» и «компонент продукта», их предполагаемое значение также включает сервисы, сервисные системы и их компоненты.

Верификация по своей сути инкрементальный процесс, потому что это выполняется на всех этапах разработки продукта и рабочих продуктов, начиная с верификации требований, с продолжающейся верификацией развивающихся рабочих продуктов и оканчивается верификацией готового продукта.

Специфические практики этой процессной области выстраиваются друг за другом в следующей последовательности:

  • Специфическая практика Выбирайте Рабочие Продукты для Верификации позволяет выявлять рабочие продукты, которые будут верифицироваться, методы, которые будут использоваться для выполнения верификации, и требования, которым должны удовлетворять каждый выбранный рабочий продукт.
  • Специфическая практика Устанавливайте Среду Верификации позволяет определить среду, которая будет использоваться для проведения верификации.
  • Специфическая практика Устанавливайте Процедуры и Критерии Верификации позволяет разработать процедуры и критерии верификации, которые согласуются с выбранными рабочими продуктами, требованиями, методами и характеристиками среды верификации.
  • Специфическая практика Выполняйте Верификацию выполняет верификацию в соответствии с имеющимися методами, процедурами и критериями.

Верификация рабочих продуктов существенно повышает вероятность того, что продукт будет отвечать требованиям заказчиков, требованиям к продукту и компонентам продукта.

Процессные области Верификация и Валидация похожи, но они касаются разных вопросов. Валидация демонстрирует, что продукт, как это обеспечено (или как это будет обеспечено), будет соответствовать своему предполагаемому использованию, в то время как верификация определяет, отражает ли рабочий продукт должным образом указанные требования. Другими словами, верификация гарантирует, что «вы сделали это правильно», тогда как валидация гарантирует, что «вы сделали правильную вещь».

Коллегиальные оценки являются важной частью верификации и обеспечивают механизмы для эффективного удаления дефектов. Важным следствием является развитие лучшего понимания рабочих продуктов и процессов, из которых они были произведены, в результате чего дефекты могут быть предотвращены и могут быть идентифицированы возможности для улучшения процессов.

Коллегиальные оценки включают методическое изучение рабочих продуктов со стороны коллег сотрудников разработавших рабочий продукт для выявления дефектов и других необходимых изменений.

Примеры методов коллегиальных оценок включают следующее:

  • Инспекции
  • Структурированный критический анализ
  • Преднамеренный рефакторинг
  • Парное программирование

В Agile среде, верификация и валидация взаимно поддерживают друг друга вследствие вовлечения заказчиков и частых релизов. Например, дефект может быть причиной преждевременного провала валидации прототипа или раннего релиза. И наоборот, ранняя и непрерывная валидация помогает обеспечить применение верификации для разработки правильного продукта. Процессные области Верификация и Валидация позволяют обеспечить системный подход к выбору рабочих продуктов, которые будут рассмотрены и протестированы, методов и среды, которые будут использоваться, а также управление, которое поможет обеспечить раннее выявление и устранение дефектов. Чем сложнее продукт, тем более системный подход необходим для проверки совместимости между требования и решениями, а также соответствия с тем как продукт будет использоваться. (См. «CMMI при использовании Agile подходов» в части I.)

Связанные процессные области

См. процессную область Разработка Требований для получения дополнительной информации о выявлении, анализе и создании требований заказчика, требований к продукту и компонентам продукта.

См. процессную область Валидация для получения дополнительной информации о демонстрации того, что продукт или компонент продукта соответствует своему предполагаемому использованию в своей предполагаемой среде.

См. процессную область Управление Требованиями для получения дополнительной информации об обеспечении согласованности между проектными работами и требованиями.

Перечень специфических целей и практик

  • СЦ 1 Подготовиться к Верификации
    • СП 1.1 Выбирайте Рабочие Продукты для Верификации
    • СП 1.2 Устанавливайте Среду Верификации
    • СП 1.3 Устанавливайте Процедуры Верификации
  • СЦ 2. Выполнить Коллегиальные Оценки
    • СП 2.1 Подготавливайтесь к Коллегиальным Оценкам
    • СП 2.2 Проводите Коллегиальные Оценки
    • СП 2.3 Анализируйте Данные Коллегиальных Оценок
  • СЦ 3 Выполнить Верификацию для Выбранных Рабочих Продуктов
    • СП 3.1 Выполняйте Верификацию
    • СП 3.2 Анализируйте Результаты Верификации

Специфические практики по целям

СЦ 1 Подготовиться к Верификации

Проведена подготовка к верификации.

Предварительная подготовка необходима для обеспечения включения положений верификаций в требования к продукту и компонентам продукта, проектирование, планов разработки и расписания работ. Верификация включает в себя отбор, инспекцию, тестирование, анализ и демонстрацию рабочих продуктов.

Методы верификации включают инспекции, коллегиальные оценки, аудиты, критические анализы, анализы, архитектуры оценки, симуляции, тестирование и демонстрации, но не ограничиваются этим. Практики, которые относятся к коллегиальным оценкам, как специфический метод верификации включены в специфическую цель 2.

Подготовка также влечет за собой определение вспомогательных инструментов, средств и программного обеспечения для тестирования, симуляций, прототипов и других средств.

СП 1.1 Выбирайте Рабочие Продукты для Верификации

Выбирайте рабочие продукты для верификации и методы верификации, которые будут использоваться.

Рабочие продукты отбираются на основе их уровня содействия в достижении целей проекта и требований, а также на основе их влияния на проектные риски.

Рабочие продукты, которые должны быть верифицированы, могут включать в себя элементы, связанные с обслуживанием, обучением и технической поддержкой. Требования к рабочим продуктам для верификации включаются с методами верификации. Методы верификации отражают подходы к верификации рабочих продуктов и специфические подходы, которые будут использоваться для верификации того что специфические рабочие продукты удовлетворяют их требованиям.

Примеры методов верификации включают в себя следующее:

  • Оценка архитектуры программного обеспечения и оценка соответствия реализации
  • Тестовое покрытие
  • Нагрузочное, стрессовое и тестирование производительности
  • Тестирование на основе таблицы решений
  • Тестирование на основе функциональной декомпозиции
  • Повторное использование тестовых сценариев
  • Приемочное тестирование
  • Непрерывная интеграция (как Agile подход, который заранее определяет проблемы интеграции)

Верификация для системной инженерии обычно включает в себя прототипирование, моделирование и симуляции для верификации адекватности систем (и распределения).

Верификация для аппаратного обеспечения как правило требует параметрический подход, который рассматривает различные условия среды (например, давление, температура, вибрация, влажность), различные диапазоны ввода (например, входная мощность может быть рассчитана от 20 В до 32 В для запланированного номинала 28В), вариации вызванные проблемами устойчивости зависимых частей и многие другие переменные. Аппаратная верификация обычно тестирует большинство переменных по отдельности в исключении случаев, когда возможны проблемы взаимодействия.

Выбор методов верификации обычно начинается с определения продукта и требований к продукту и компонентам продукта для оценки того, что требования проверяемы. При повторной верификации методы верификации направлены на проверку того, что изменения рабочих продуктов не приводят к непреднамеренным дефектам. Поставщики должны быть вовлечены в этот выбор, чтобы проектные методы соответствовали среде поставщика.

Пример рабочих продуктов

1. Списки рабочих продуктов, выбранных для верификации

2. Методы верификации для каждого выбранного рабочего продукта

Подпрактики

1. Определяйте рабочие продукты для верификации.

2. Определяйте требования, которым должны удовлетворять каждый выбранный рабочий продукт.

См. специфическую практику Поддерживайте Двунаправленную Трассировку Требований процессной области Управление Требованиями для получения дополнительной информации о трассировке требований с рабочими продуктами.

3. Определяйте методы верификации, доступные для использования.

4. Определяйте методы верификации, которые будут использоваться для каждого выбранного рабочего продукта.

5. Запланируйте интеграцию плана проекта и идентификацию рабочих продуктов, которые должны быть верифицированы, требования, которые должны быть удовлетворены, и методы, которые будут использоваться.

См. процессную область Планирование Проекта для получения дополнительной информации о разработке плана проекта.

СП 1.2 Устанавливайте Среду Верификации

Устанавливайте и поддерживайте среду, необходимую для поддержки верификации.

Среда должна быть установлена для возможности проведения верификации. Среда верификации может быть приобретена, разработана, повторно использована, модифицирована или получена с помощью комбинации этих мероприятий в зависимости от потребностей проекта.

Необходимый тип среды зависит от рабочих продуктов, отобранных для верификации и используемых методов верификации. Коллегиальная оценка может потребовать немного больше, чем пакет материалов, рецензент и комната. Тестирование продукта может потребовать симуляторы, эмуляторы, генераторы сценариев, инструменты обработки данных, контроля среды, а также взаимодействие с другими системами.

Пример рабочих продуктов

1. Среда верификации

Подпрактики

1. Определяйте требования к среде верификации.

2. Определяйте ресурсы верификации, которые доступны для повторного использования или модификации.

3. Определяйте оборудование и инструменты верификации.

4. Приобретайте оборудование и среду для поддержки верификации (например, оборудование для тестирования, программное обеспечение).

СП 1.3 Устанавливайте Процедуры и Критерии Верификации

Устанавливайте и поддерживайте процедуры и критерии верификации для выбранных рабочих элементов.

Критерии верификации определяются для обеспечения того что рабочие продукты соответствуют их требованиям.

Примеры источников для критериев верификации включают в себя следующее:

  • Требования к продукту и компонентам продукта
  • Стандарты
  • Организационные политики
  • Тип тестирования
  • Параметры тестирования
  • Параметры для взвешенного выбора между качеством и стоимостью тестирования
  • Тип рабочих продуктов
  • Поставщики
  • Предложения и соглашения
  • Оценка рабочих продуктов заказчика совместно с разработчиками

Пример рабочих продуктов

1. Процедуры верификации

2. Критерии верификации

Подпрактики

1. Создавайте по мере необходимости набор комплексных, интегрированных процедур верификации для рабочих продуктов и для коммерческих готовых продуктов.

2. Разрабатывайте и уточняйте по мере необходимости критерии верификации.

3. Определяйте ожидаемые результаты, допустимые отклонения и другие критерии для удовлетворения требований.

4. Определяйте оборудование и компоненты среды, необходимые для поддержки верификации.

СЦ 2 Выполнить Коллегиальные Оценки

Коллегиальные оценки выполнены для выбранных рабочих продуктов

Коллегиальные оценки связаны с методическим изучением рабочих продуктов со стороны коллег сотрудников разработавших рабочий продукт для выявления дефектов для удаления и рекомендации других необходимых изменений.

Коллегиальная оценка является важным и эффективным методом верификации осуществляемой через инспекции, структурированный критический анализ или ряд других методов коллегиальной оценки.

Коллегиальные оценки в основном применяются для рабочих продуктов, разработанных в проекте, но они также могут быть применены для других рабочих продуктов, например, рабочие продукты документации и обучения, которые обычно разрабатываются группами поддержки.

СП 2.1 Подготавливайтесь к Коллегиальным Оценкам

Подготавливайтесь к коллегиальным оценкам для выбранных рабочих продуктов.

Мероприятия по подготовке коллегиальных оценок обычно включают в себя выявление сотрудников, которым будет предложено принять участие в коллегиальной оценке для каждого рабочего продукта, определение ключевых рецензентов, которые должны участвовать в коллегиальной оценке, подготовка и обновление материалов, которые будут использоваться во время проведения коллегиальных оценок, такие как контрольные списки и критерии оценки, и календарное планирование коллегиальных оценок.

Пример рабочих продуктов

1. График коллегиальных оценок

2. Контрольный список коллегиальной оценки

3. Критерии начала и окончания для рабочих продуктов

4. Критерии, которые описывают требования для необходимости проведения другой коллегиальной оценки

5. Коллегиальная оценка учебных материалов

6. Выбранные для рецензирования рабочие продукты

Подпрактики

1. Определяйте тип коллегиальной оценки, которая будет проводиться.

Примеры типов коллегиальных оценок включают следующее:

  • Инспекции
  • Структурированный критический анализ
  • Активное рецензирование
  • Оценка соответствия архитектуры реализации

2. Определяйте требования для сбора данных в ходе коллегиальной оценки.

См. процессную область Измерения и Анализ для получения дополнительной информации о получении данных измерений.

3. Устанавливайте и поддерживайте критерии начала и окончания для коллегиальной оценки.

4. Устанавливайте и поддерживайте критерии, которые описывают требования для необходимости проведения другой коллегиальной оценки.

5. Устанавливайте и поддерживать контрольные списки для подтверждения того, что рабочие продукты проверяются последовательно.

Примеры элементов, затрагиваемых контрольными списками, включают следующее:

  • Правила построения
  • Руководства для проектирования
  • Полнота
  • Правильность
  • Возможность поддержки
  • Общие типы дефектов

Контрольные списки изменяются по мере необходимости для конкретного типа рабочего продукта и коллегиальной оценки. Коллеги сотрудников разработавших контрольный список и потенциальные конечные пользователи рецензируют контрольные списки.

6. Разрабатывайте детальный календарный график коллегиальной оценки, в том числе даты для обучения коллегиальным оценкам и того, когда материалы для проведения коллегиальных оценок будут доступны.

7. Убедитесь, что рабочий продукт удовлетворяет критериям начала коллегиальной оценки перед его передачей.

8. Заранее распределяйте рабочие продукты для оценки и соответствующую информацию для участников, чтобы дать им возможность адекватно подготовиться к коллегиальной оценке.

9. Назначайте в случае необходимости роли для коллегиальной оценки.

Примеры роли включают следующее:

  • Руководитель
  • Читатель
  • Записывающий
  • Автор

10. Подготавливайтесь к коллегиальной оценке, просматривая рабочие продукты до проведения коллегиальной оценки.

СП 2.2 Проводите Коллегиальные Оценки

Проводите коллегиальные оценки для рабочих продуктов и идентифицируйте проблемы, полученные в результате этих оценок.

Одной из целей проведения коллегиальной оценки является поиск и устранение дефектов на ранней стадии. Коллегиальные оценки выполняются постепенно по мере того как рабочие продукты разрабатываются. Эти оценки структурированы и не являются управленческими оценками.

Коллегиальные оценки могут быть выполнены для спецификации ключевых рабочих продуктов, проектирования, тестирования и мероприятий по реализации и специфических рабочих продуктов планирования.

В центре внимания коллегиальной оценки должно быть анализ рабочего продукта, а не человека, который разработал его.

Если возникают проблемы во время коллегиальной оценки, то они должны быть доведены до сведения основному разработчику рабочего продукта для корректировки.

См. процессную область Мониторинг и Контроль Проекта для получения дополнительной информации о мониторинге проекта на соответствие плану.

Коллегиальные оценки должны учитывать следующие правила: должна быть достаточная подготовка, выполнение должно быть управляемо и контролируемо, последовательные и достаточные данные должны быть записаны (например, проведение формальной инспекции) и действия должны быть записаны.

Пример рабочих продуктов

1. Результаты коллегиальных оценок

2. Проблемы коллегиальных оценок

3. Данные коллегиальных оценок

Подпрактики

1. Следуйте назначенным ролям в коллегиальной оценке.

2. Выявляйте и документируйте дефекты и другие проблемы в рабочих продуктах.

3. Записывайте результаты коллегиальной оценки, в том числе конкретные действия.

4. Собирайте данные коллегиальных оценок.

См. процессную область Измерения и Анализ для получения дополнительной информации о получении данных измерений.

5. Определяйте конкретные действия и сообщайте проблемы соответствующим заинтересованным сторонам.

6. Проводите дополнительную коллегиальную оценку в случае необходимости.

7. Убедитесь, что выходные критерии для коллегиальной оценки выполняются.

СП 2.3 Анализируйте Данные Коллегиальных Оценок

Анализируйте данные подготовки, выполнения и результатов коллегиальных оценок.

См. процессную область Измерения и Анализ для получения дополнительной информации о получении данных измерений и анализе данных измерений.

Пример рабочих продуктов

1. Данные коллегиальных оценок

2. Конкретные действия для коллегиальных оценок

Подпрактики

1. Записывайте данные по подготовке, проведению и результатах коллегиальных оценок.

Типичные данные – это название продукта, размер продукта, состав команды коллегиальной оценки, тип коллегиальной оценки, время подготовки рецензента, длина совещания коллегиальной оценки, количество найденных дефектов, тип и происхождение дефекта и так далее. Может быть собрана дополнительная информация о рецензируемом рабочем продукте, например, размер, стадия разработки, рассмотренные режимы работы, а также оцениваемые требования.

2. Храните данные для дальнейшего использования и анализа.

3. Защищайте данные, чтобы гарантировать, что данные коллегиальных оценок используются по назначению.

Примеры неправильного использования данных коллегиальных оценок включают в себя использование данных для оценки работы людей и использование данных для установки атрибутов.

4. Анализируйте данные коллегиальных оценок.

Примеры данных коллегиальных оценок, которые могут быть проанализированы, включают следующее:

  • Фаза, в которой введен дефект
  • Время или скорость подготовки в сравнении с ожидаемым временем или скоростью
  • Количество дефектов в сравнении с числом ожидаемых
  • Типы обнаруженных дефектов
  • Причины дефектов
  • Влияние решения дефектов
  • Пользовательские истории или анализ практических сценариев связанных с дефектом
  • Конечные пользователи и заказчики, которые связаны с дефектами

СЦ 3 Выполнить Верификацию Выбранных Рабочих Продуктов

Выбранные рабочие продукты верифицированы на соответствие их указанным требованиям.

Методы, процедуры и критерии верификации используются для верификации выбранных рабочих продуктов и связанных с ними технической поддержки, обучения и сервисной поддержки, используя соответствующую среду верификации. Мероприятия по верификации должны выполняться на протяжении всего жизненного цикла продукта. Практики, относящиеся к коллегиальным оценкам, как специфический метод верификации включены в специфическую цель 2.

СП 3.1 Выполняйте Верификацию

Выполняйте верификацию для выбранных рабочих продуктов.

Верификация продуктов и рабочих продуктов инкрементально способствует раннему выявлению проблем и может привести к раннему удалению дефектов. Результаты проверки помогают сохранить значительные средства, которые необходимы для локализации ошибок и переделок, связанных с устранением проблем.

Пример рабочих продуктов

1. Результаты верификации

2. Отчеты верификации

3. Демонстрации

4. Журнал процедур запуска

Подпрактики

1. Выполняйте проверку выбранных рабочих продуктов на основе их требований.

2. Записывайте результаты мероприятий по верификации.

3. Определяйте конкретные действия на основе результатов верификации рабочих продуктов.

4. Документируйте методы запуска верификации и отклонения от существующих методов и процедур, обнаруженных в ходе их работы.

СП 3.2 Анализируйте Результаты Верификации

Анализируйте результаты мероприятий верификации.

Фактические результаты должны быть сопоставлены с установленными критериями проверки, чтобы определить приемлемость.

Результаты анализа записываются в качестве доказательства того, что верификация была проведена.

Для каждого рабочего продукта все имеющиеся результаты верификации постепенно анализируются, чтобы убедиться, что требования были выполнены. Т.к. коллегиальная оценка является одним из нескольких методов верификация, данные коллегиальной оценки должны быть включены в эти мероприятия по анализу, чтобы результаты верификации были проанализированы в достаточной степени.

Отчеты по анализу или документация по запуску методов могут также показать, что плохие результаты верификации связаны с проблемами методов, проблемами критериев или проблемами среды верификации.

Пример рабочих продуктов

1. Отчет об анализе (например, статистические данные о производительности, причинно-следственный анализ несоответствий, сравнение поведения между реальным продуктом и моделями, тенденции)

2. Отчеты о проблемах

3. Запросы на изменение для методов, критериев и условий верификации

Подпрактики

1. Сравнивайте фактические результаты с ожидаемыми результатами.

2. На основании установленных критериев верификации, выявляйте продукты, которые не соответствуют их требованиями, или выявляйте проблемы с методами, критериями или средой верификации.

3. Анализируйте данные о дефектах.

4. Записывайте все результаты анализа в отчеты.

5. Используйте результаты верификации для сравнения фактических измерений и работы на соответствие техническим параметрам производительности.

6. Предоставляйте информацию о том, как дефекты могут быть решены (включая методы, критерии и среду верификации) и инициируйте корректирующие действия.

См. процессную область Мониторинг и Контроль Проекта для получения дополнительной информации об управлении корректирующими действиями.

Posted in CMMI, Стандарты и методологии | Отмечено: , , , | Leave a Comment »

CMMI DEV v1.3 – Валидация

Posted by Шамрай Александр на Июль 20, 2011

Перевод Шамрай А.В.

Инженерная процессная область уровня зрелости 3

Назначение

Назначением Валидации (ВАЛ) является демонстрация того, что продукт или компонент продукта соответствует своему предполагаемому использованию в его предполагаемой среде.

Вступительный комментарий

Мероприятия валидации могут быть применены ко всем аспектам продукта в любой из его предполагаемых сред, таких как операционная деятельность, обучение, производство, обслуживание и сервисы поддержки. Методы, используемые для выполнения валидации, могут быть применены к рабочим продуктам, а также продуктам и компонентам продукта. (В этой процессной области, где используются термины «продукт» и «компонент продукта», их предполагаемое значение также включает сервисы, системы обслуживания и их компоненты). Рабочие продукты (например, требования, проектирование, прототипы) должны быть выбраны на основе лучших предикторов того, насколько хорошо продукт и компоненты продукта будут удовлетворять потребности конечных пользователей, и, следовательно, валидация выполняется на ранних этапах (концепция / обследование) и инкрементально на протяжении всего жизненного цикла продукта (в том числе при переходе к операционному использованию и внутреннему обслуживанию).

Среда валидации должна представлять предполагаемую среду для продукта и компонентов продукта, а также представлять предполагаемую среду, подходящую для действий валидации с рабочими продуктами.

Валидация показывает, что продукт, как предусмотрено, будет соответствовать своему предполагаемому использованию, тогда как верификация проверяет, соответствует ли рабочий продукт должным образом установленным требованиям. Другими словами, верификация гарантирует, что «вы сделали это правильно», тогда как валидация гарантирует, что «вы сделали правильную вещь». Мероприятия валидации используют подходы, которые схожи с верификацией (например, тестирование, анализ, инспекции, демонстрация, симуляция). Часто конечные пользователи и другие соответствующие заинтересованные стороны участвуют в процессе валидации. И валидация, и верификация часто выполняются параллельно и могут использовать части той же среды.

См. процессную область Верификация для получения дополнительной информации о проверке того, что выбранные рабочие продукты удовлетворяют их требованиям.

Когда это возможно, валидация должна быть выполнена с операционным использованием продукта или компонента продукта в его предполагаемой среде. Может быть использована вся среда или только ее часть. Тем не менее, проблемы валидации могут быть обнаружены в начале жизненного цикла проекта с использованием рабочих продуктов с участием соответствующих заинтересованных сторон. Мероприятия валидации для сервисов могут быть применены к рабочим продуктам, такие как предложения, перечень сервисов, устав работ и журнал сервисов.

Когда проблемы валидации идентифицированы, для принятия решения они взаимодействуют с процессами, связанными с процессными областями Разработка Требований, Техническое Решение или Мониторинг и Контроль Проекта.

Специфические практики этой процессной области выстроены друг за другом следующим образом:

  • Специфическая практика Выбирайте Продукты для Валидации позволяет выявить продукт или компонент продукта для валидации и методы, которые будут использоваться для выполнения валидации.
  • Специфическая практика Устанавливайте Среду Валидации позволяет определить среду, которая будет использоваться для проведения валидации.
  • Специфическая практика Устанавливайте Процедуры Валидации позволяет разработать процедуры и критерии валидации, которые приведены в соответствие с характеристиками выбранных продуктов, ограничениями заказчика для валидации, методами и средой валидации.
  • Специфическая практика Выполняйте Валидацию позволяет выполнить валидацию в соответствии с методами, процедурами и критериями.

Связанные процессные области

См. процессную область Разработка Требований для получения дополнительной информации о выявлении, анализе и создании требований заказчика, требований к продукту и компонентам продукта.

См. процессную область Техническое Решение для получения дополнительной информации о выборе, проектировании и реализации решения для требований.

См. процессную область Верификация для получения дополнительной информации проверке того, что выбранные рабочие продукты соответствуют их требованиям.

Перечень специфических целей и практик

  • СЦ 1 Подготовиться к Валидации
    • СП 1.1 Выбирайте Продукты для Валидации
    • СП 1.2 Устанавливайте Среду Валидации
    • СП 1.3 Устанавливайте Процедуры Валидации
  • СЦ 2 Выполнить Валидацию Продукта или Компонента Продукта
    • СП 2.1 Выполняйте Валидацию
    • СП 1.6 Анализируйте Результаты Валидации

Специфические практики по целям

СЦ 1 Подготовиться к Валидации

Проведена подготовка к валидации.

Мероприятия по подготовке включают выбор продуктов и компонентов продукта для валидации, установку и поддержку среды, процедур и критериев валидации. Компоненты, отобранные для валидации, могут включать только продукт или они могут включать соответствующие уровни компонентов продукта, используемых для создания продукта. Любой продукт или компонент продукта может быть предметом валидации, в том числе продукты для замены, обслуживания, учебные материалы и многое другое.

Среда, необходимая для валидации продукта или компонента продукта, должна быть подготовлена. Среда может быть куплена или может быть определена, спроектирована и собрана. Среды для интеграции продукта и верификации могут быть размещены вместе со средой валидации для снижения затрат и повышения эффективности или производительности.

СП 1.1 Выбирайте Продукты для Валидации

Выбирайте продукты и компоненты продукта для валидации и методы валидации, которые будут использоваться.

Продукты и компоненты продукта отбираются для валидации на основе их связи с потребностями конечных пользователей. Для каждого компонента продукта должны быть определены границы валидации (например, операционное поведение, обслуживание, обучение, пользовательский интерфейс).

Примеры продуктов и компонентов продукта, которые могут быть проверены, включают следующее:

  • Требования и элементы проектирования для продукта и компонентов продукта
  • Продукт и компоненты продукта (например, система, аппаратные компоненты, программное обеспечение, сервисная документация)
  • Интерфейсы пользователя
  • Руководства пользователя
  • Учебные материалы
  • Процессная документация
  • Протоколы доступа
  • Форматы отчетных данных обмена

Собираются требования и ограничения для проведения валидации. Затем отбираются методы валидации на основе их способности продемонстрировать, что потребности конечных пользователей удовлетворены. Методы валидации не только определяют подход к валидации продукта, но и управляют потребностями в средствах, оборудовании и средах. Подходы и потребности валидации могут быть получены в результате создания требований компонента продукта низкого уровня, которые управляются процессами разработки требований. Также могут быть получены производные требования, такие как интерфейсные требования для наборов тестов и тестового оборудования. Эти требования также передаются из процессов разработки требований для обеспечения того, что продукт или компоненты продукта могут быть проверены в среде, которая поддерживает методы.

Методы валидации должны быть выбраны в начале жизненного цикла проекта, чтобы они четко были понятны и утверждены с соответствующими заинтересованными сторонами.

Методы валидации по мере необходимости направлены на проблемы разработки, обслуживания, поддержки и обучения для продукта или компонентов продукта.

Примеры методов валидации включают в себя следующее:

  • Обсуждения с конечными пользователями, возможно, в контексте официального рассмотрения
  • Демонстрации прототипов
  • Функциональные демонстрации (например, системы, аппаратных компонентов, программного обеспечения, документации обслуживания, пользовательских интерфейсов)
  • Пилоты учебных материалов
  • Тестирование продуктов и компонентов продукта конечными пользователями и другими заинтересованными сторонами
  • Инкрементальные поставки работающих и потенциально приемлемых продуктов
  • Анализ продукта и компонентов продукта (например, симуляция, моделирование, пользовательский анализ)

Валидация аппаратной части включает моделирование для проверки формы, размеров и функции механических конструкций, термического моделирования, анализа ремонтопригодности и надежности, повременные демонстрации и проектировочные симуляции электрических схем для электронных или механических компонентов продукта.

Пример рабочих продуктов

1. Списки продуктов и их компонентов, выбранных для валидации

2. Методы валидации для каждого продукта или компонента продукта

3. Требования для проведения валидации для каждого продукта или компонента продукта

4. Ограничения валидации для каждого продукта или компонента продукта

Подпрактики

1. Определяйте основные принципы, возможности и этапы для валидации продукта или компонента продукта в течение всей жизни проекта.

2. Определяйте, какие категории потребностей конечных пользователей (операционные, техническое обслуживание, обучение или поддержка) должны быть проверены.

Продукт или компонент продукта должен быть сопровождаемы и поддерживаемы в его предполагаемой операционной среде. Данная специфическая практика также направлена на фактическое техническое обслуживание, обучение и сервисы поддержки, которые могут поставляться с продуктом.

Пример валидации концепции обслуживания в операционной среде является демонстрация того, что инструменты обслуживания работают с реальным продуктом.

3. Выбирайте продукт и компоненты продукта для проверки.

4. Выбирайте методы валидации продукта или компонента продукта.

5. Рассматривайте выбранные компоненты для валидации, ограничения и методы с соответствующими заинтересованными сторонами.

СП 1.2 Устанавливайте Среду Валидации

Устанавливайте и поддерживайте среду, необходимую для поддержки валидации.

Требования к среде валидации обуславливаются выбранными продуктом или компонентами продукта, типом рабочих продуктов (например, элемент проектирования, прототип, финальная версия), а также методами валидации. Эти наборы могут привести к требованиям для приобретения или разработки оборудования, программного обеспечения или других ресурсов. Эти требования передаются в процессы разработки требований для разработки. Среда валидации может включать в себя повторное использование имеющихся ресурсов. В этом случае, должны быть обеспечены механизмы для использования этих ресурсов.

Пример типов элементов среды валидации включают следующее:

  • Инструменты тестирования сопряженные с продуктом для валидации (например, контекст, электронные устройства, датчики)
  • Временно встроенное программное обеспечение тестирования
  • Записывающие инструменты для записи или дальнейшего анализа и воспроизведения
  • Имитирующие подсистемы или компоненты (например, программное обеспечение, электроника, механизмы)
  • Имитирующие системы для взаимодействия (например, фиктивный военный корабль для тестирования военно-морского радара)
  • Реальные системы для взаимодействия (например, самолет для тестирования радара на удобство слежения траектории)
  • Средства и продукты предоставляемые заказчиком
  • Квалифицированные сотрудники для операционного взаимодействия или использования всех предыдущих элементов
  • Специальные вычислительные или сетевая тестовая среда (например, тестовые стенды псевдо-эксплуатационнных телекоммуникационных сетей или установок с реальными соединениями, коммутаторами и системами, установленными для реальной интеграции и проверок валидации)

Проведение заранее выбора продуктов или компонентов продукта для валидации, рабочих продуктов для использования в валидации и методов валидации необходимы для обеспечения того, что среда валидации будет доступна при первой необходимости.

Среда валидации должна тщательно контролироваться для обеспечения репликации, анализа результатов и повторной валидации проблемных областей.

Пример рабочих продуктов

1. Среда валидации

Подпрактики

1. Определяйте требования к среде валидации.

2. Определяйте предоставляемые заказчиком продукты.

3. Определяйте оборудование и инструменты тестирования.

4. Определяйте ресурсы валидации, которые доступны для повторного использования и модификации.

5. Детально планируйте наличие ресурсов.

СП 1.3 Установите Процедуры и Критерии Валидации

Устанавливайте и поддерживайте процедуры и критерии для валидации.

Процедуры и критерии валидации определяются для того, чтобы убедиться, что продукт или компонент продукта будет соответствовать своему предполагаемому использованию в его предполагаемой среде. Тестовые сценарии и процедуры для приемо-сдаточных испытаний могут быть использованы как процедуры валидации.

Процедуры и критерии валидации включают в себя тестирование и оценку технического обслуживания, обучения и сервисов поддержки.

Примеры источников для критериев валидации включают в себя следующее:

  • Требования к продукту и компонентам продукта
  • Стандарты
  • Критерии приемки заказчика
  • Показатели производительности
  • Отклонения от пороговых показателей производительности

Пример рабочих продуктов

1. Процедуры валидации

2. Критерии валидации

3. Процедуры тестирования и оценки для технического обслуживания, обучения и поддержки

Подпрактики

1. Рецензируйте требования к продукту для обеспечения того, что проблемы, касающиеся валидации продукта или компонента продукта, были выявлены и устранены.

2. Документируйте среду, операционные сценарии, процедуры, входы, выходы и критерии для валидации выбранного продукта или компонента продукта.

3. Оценивайте проектирование по мере его развития в контексте среды валидации для выявления проблем валидации.

СЦ 2 Выполнить Валидацию Продукта или Компонента Продукта

Для продукта или компонентов продукта проведена валидация для проверки того, что они пригодны для использования в их предполагаемой операционной среде.

Методы, процедуры и критерии валидации, используемые для валидации выбранных продуктов и компонентов продукта и любых связанных вопросов с обслуживанием, обучением и сервисов поддержки, используют соответствующую среду валидации. Мероприятия валидации выполняются в течение всего жизненного цикла продукта.

СП 2.1 Выполняйте Валидацию

Выполняйте валидацию для выбранных продуктов или компонентов продукта.

Чтобы быть приемлемым для заинтересованных сторон, продукт или компонент продукта должен работать как ожидалось в его предполагаемой операционной среде.

Мероприятия валидации выполняются, и результирующие данные собираются в соответствии с установленными методами, процедурами и критериями.

Процедуры запуска валидации должны быть документированы и отклонения, возникающие в процессе исполнения, следует отмечать по мере необходимости.

Пример рабочих продуктов

1. Отчеты валидации

2. Результаты валидации

3. Матрицы перекрестных ссылок валидации

4. Журнал процедур запуска

5. Операционные демонстрации

СП 2.2 Анализируйте Результаты Валидации

Анализируйте результаты мероприятий валидации.

Данные, которые получаются в результате тестов валидации, инспекций, демонстраций или оценки, анализируются на соответствие определенным критериям валидации. Анализ отчетов показывают, были ли потребности удовлетворены. В случае отклонений, эти отчеты документируют степень успеха или неудачи и классифицируют возможные причины отказа. Собранные результаты теста, инспекции или проверки сравниваются с установленными критериями оценки для определения необходимости продолжать или адресовать требования или вопросы проектирования в процессы разработки требований или технического решения.

Анализ отчетов или документации запуска валидации может также показать, что плохие результаты теста были из-за проблем процедур валидации или проблем среды валидации.

Пример рабочих продуктов

1. Отчеты об отклонениях валидации

2. Проблемы валидации

3. Запрос на изменение процедуры

Подпрактики

1. Сравнивайте фактические результаты с ожидаемыми результатами.

2. На основании установленных критериев валидации, выявляйте продукты и компоненты продукта, которые не работают соответствующе в предполагаемой операционной среде, или выявляйте проблемы с методами, критериями или средой.

3. Анализируйте данные валидации на наличие дефектов.

4. Записывайте результаты анализа и выявленные проблемы.

5. Используйте результаты валидации для сравнения фактических измерений и работы на соответствие необходимому использованию или операционным потребностям.

6. Предоставляйте информацию о том, как дефекты могут быть решены (включая методы, критерии и среду валидации) и инициируйте корректирующие действия.

См. процессную область Мониторинг и Контроль Проекта для получения дополнительной информации об управлении корректирующими действиями.

Posted in CMMI, Стандарты и методологии | Отмечено: , , , | Leave a Comment »

 
%d такие блоггеры, как: