SEI CMMI — Обзор

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

Что такое CMM?

• CMM обозначает C apability M aturity M odel.

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

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

• CMM — это метод оценки и оценки зрелости процесса разработки программного обеспечения в организации.

• CMM измеряет зрелость процесса разработки программного обеспечения по шкале от 1 до 5.

• CMM v1.0 был разработан Институтом разработки программного обеспечения (SEI) в Университете Карнеги-Меллона в Питтсбурге, США.

• Изначально CMM был разработан для разработки и сопровождения программного обеспечения, но позже —

  • Системная инженерия

  • Поставщик Поставщик

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

  • Люди ШМ

  • Приобретение программного обеспечения

CMM обозначает C apability M aturity M odel.

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

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

CMM — это метод оценки и оценки зрелости процесса разработки программного обеспечения в организации.

CMM измеряет зрелость процесса разработки программного обеспечения по шкале от 1 до 5.

CMM v1.0 был разработан Институтом разработки программного обеспечения (SEI) в Университете Карнеги-Меллона в Питтсбурге, США.

Изначально CMM был разработан для разработки и сопровождения программного обеспечения, но позже —

Системная инженерия

Поставщик Поставщик

Комплексная разработка продуктов и процессов

Люди ШМ

Приобретение программного обеспечения

Примеры CMM

• Люди CMM — Развивайте, мотивируйте и сохраняйте талант проекта.

• Software CMM — Расширение возможностей разработки и сопровождения программного обеспечения.

Люди CMM — Развивайте, мотивируйте и сохраняйте талант проекта.

Software CMM — Расширение возможностей разработки и сопровождения программного обеспечения.

Что такое зрелость?

Определения меняются, но обычно считается, что зрелые процессы —

• Четкая,

• Повторяется,

• Измеряется,

• Проанализировано,

• Улучшено, и

• Эффективное.

Четкая,

Повторяется,

Измеряется,

Проанализировано,

Улучшено, и

Эффективное.

Плохие, но зрелые процессы так же плохи, как и отсутствие зрелости!

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

Незрелая против зрелой организации

Незрелая организация будет иметь следующие характеристики —

• Процесс импровизированный во время проекта

• Одобренные процессы игнорируются

• Реактивный, не активный

• Нереальный бюджет и график

• Качество пожертвовано для графика

• Нет объективной оценки качества

Процесс импровизированный во время проекта

Одобренные процессы игнорируются

Реактивный, не активный

Нереальный бюджет и график

Качество пожертвовано для графика

Нет объективной оценки качества

В отличие от этого, характеристики зрелой организации следующие:

• Межгрупповое общение и координация

• Работа выполнена в соответствии с планом

• Практики в соответствии с процессами

• Процессы обновляются по мере необходимости

• Четко определенные роли / обязанности

• Управление формально обязуется

Межгрупповое общение и координация

Работа выполнена в соответствии с планом

Практики в соответствии с процессами

Процессы обновляются по мере необходимости

Четко определенные роли / обязанности

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

Что такое CMMI?

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

• Модель зрелости возможностей для программного обеспечения (SW-CMM) — v2.0 Draft C.

• Промежуточный стандарт Альянса электронной промышленности (EIA / IS) — 731 Системная инженерия.

• Модель зрелости для комплексной разработки продукта (IPD-CMM) v0.98.

Модель зрелости возможностей для программного обеспечения (SW-CMM) — v2.0 Draft C.

Промежуточный стандарт Альянса электронной промышленности (EIA / IS) — 731 Системная инженерия.

Модель зрелости для комплексной разработки продукта (IPD-CMM) v0.98.

Интеграция CMM

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

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

• Устанавливает основу для интеграции будущих моделей.

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

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

Устанавливает основу для интеграции будущих моделей.

Разница между CMM и CMMI

CMM является эталонной моделью зрелых практик в определенной дисциплине, такой как системная инженерия CMM, Software CMM, People CMM, Software Acquisition CMM и т. Д., Но их было сложно интегрировать по мере необходимости.

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

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

CMMI и бизнес-цели

Цели CMMI очень очевидны. Они заключаются в следующем —

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

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

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

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

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

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

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

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

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

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

Модели SEI CMMI — Дисциплины

Интеграция CMM — это модель, которая объединяет несколько дисциплин / совокупностей знаний. В настоящее время для выбора модели CMMI вам доступны четыре области знаний.

Системная инженерия

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

Программная инженерия

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

Комплексная разработка продуктов и процессов

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

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

Поставщик Поставщик

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

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

Выбор дисциплины CMMI

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

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

• Если вы улучшаете свои интегрированные процессы разработки продуктов и процессов, такие как Integrated Teaming, Organisation Environment for Integration, вам следует выбрать IPPD. Усиление дисциплины для IPPD получает особый акцент.

• Если вы улучшаете процессы выбора источника, такие как «Интегрированное управление поставщиками», вам следует выбрать «Выбор поставщиков» (SS). Усиление дисциплины для поиска поставщиков получает особый акцент.

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

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

Если вы улучшаете свои интегрированные процессы разработки продуктов и процессов, такие как Integrated Teaming, Organisation Environment for Integration, вам следует выбрать IPPD. Усиление дисциплины для IPPD получает особый акцент.

Если вы улучшаете процессы выбора источника, такие как «Интегрированное управление поставщиками», вам следует выбрать «Выбор поставщиков» (SS). Усиление дисциплины для поиска поставщиков получает особый акцент.

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

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

SEI CMMI — Представительства

CMMI имеет следующую структуру:

• Уровни зрелости (поэтапное представление) или Уровни возможностей (непрерывное представление)
• Области деятельности
• Цели: общие и конкретные
• Общие черты
• Практики: общие и специфические

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

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

Постановочное Представление

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

Постановочное представление CMMI

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

• Позволяет сравнения между и между организациями по уровням зрелости.

• Обеспечивает легкую миграцию с SW-CMM на CMMI.

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

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

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

Обеспечивает легкую миграцию с SW-CMM на CMMI.

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

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

Постановочная структура CMMI

Следующая картинка иллюстрирует структуру поэтапной модели CMMI.

Непрерывное представление

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

CMMI непрерывного представительства

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

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

• Обеспечивает легкий переход от EIA 731 (и других моделей с непрерывным представлением) к CMMI.

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

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

Обеспечивает легкий переход от EIA 731 (и других моделей с непрерывным представлением) к CMMI.

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

CMMI непрерывная структура

На следующем рисунке показана структура непрерывной модели CMMI.

Непрерывное и поэтапное представление

Непрерывное представление	Постановочное Представление
Области процесса организованы по категориям областей процесса.	Области процесса организованы по уровням зрелости.
Улучшение измеряется с использованием уровней возможностей. Уровни возможностей измеряют зрелость определенного процесса в организации; оно колеблется от 0 до 5.	Улучшение измеряется с использованием уровней зрелости. Уровни зрелости измеряют зрелость набора процессов в организации: он варьируется от 1 до 5.
Существует два типа специальных практик: базовый и расширенный. Все конкретные практики появляются в непрерывном представлении.	Существует только один тип конкретной практики. Понятия базовых и передовых практик не используются. Все конкретные практики появляются в поэтапном представлении, за исключением случаев, когда в непрерывном представлении появляется пара базовых расширенных практик, и в этом случае в поэтапном представлении появляется только расширенная практика.
Уровни возможностей используются для организации общих практик.	Общие функции используются для организации общих практик.
Все общие практики включены в каждую область процесса.	Включены только общие практики уровня 2 и уровня 3.
Эквивалентная постановка позволяет определить уровень зрелости из профиля достижений организации.	Нет необходимости в механизме эквивалентности для поддержки непрерывного представления, поскольку каждая организация может выбирать, что улучшать и сколько улучшать, используя поэтапное представление.

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

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

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

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

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

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

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

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

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

Включены только общие практики уровня 2 и уровня 3.

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

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

Какое представление лучше?

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

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

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

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

CMMI — уровни зрелости

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

Модели CMMI с поэтапным представлением имеют пять уровней зрелости, обозначенных номерами от 1 до 5. Они —

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

Уровни зрелости поэтапного представления CMMI

На следующем рисунке показаны уровни зрелости в поэтапном представлении CMMI.

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

Сведения об уровне зрелости

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

Уровень зрелости 1 Начальный

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

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

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

Уровень зрелости 2 Управляемый

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

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

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

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

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

Уровень зрелости 3 определен

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

На уровне зрелости 3 процессы хорошо охарактеризованы и поняты и описаны в стандартах, процедурах, инструментах и ​​методах.

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

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

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

Уровень зрелости 4 Количественно управляемый

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Уровни зрелости не должны быть пропущены

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

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

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

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

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

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

Уровни зрелости и области процессов

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

В этом разделе приведены имена связанных областей процесса. Для получения более подробной информации об этих областях процессов см. Главу Области процессов CMMI.

уровень	фокус	Ключевая область процесса	Результат
5 Оптимизация	Непрерывное улучшение процесса	Организационные инновации и развертывание Причинный анализ и разрешение	Высочайшее качество / самый низкий риск
4 Количественно управляемый	Количественно управляемый	Эффективность организационного процесса Количественное управление проектами	Более высокое качество / меньший риск
3 определенный	Процесс стандартизации	Разработка требований Техническое решение Интеграция продуктов верификация Проверка Фокус организационного процесса Определение организационного процесса Организационное обучение Комплексный проект Mgmt (с дополнениями IPPD) Управление рисками Анализ решений и разрешение Интегрированная группировка (только IPPD) Org. Среда для интеграции (только IPPD) Интегрированное управление поставщиками (только SS)	Среднее качество / средний риск
2 Удалось	Основное управление проектом	Управление требованиями Планирование проекта Мониторинг и контроль проекта Управление соглашениями с поставщиками Измерение и анализ Обеспечение качества процесса и продукции Управление конфигурацией	Низкое качество / высокий риск
1 начальный	Процесс неформальный и Adhoc		Самое низкое качество / самый высокий риск

Оптимизация

Организационные инновации и развертывание

Причинный анализ и разрешение

Количественно управляемый

Эффективность организационного процесса

Количественное управление проектами

определенный

Разработка требований

Техническое решение

Интеграция продуктов

верификация

Проверка

Фокус организационного процесса

Определение организационного процесса

Организационное обучение

Комплексный проект Mgmt (с дополнениями IPPD)

Управление рисками

Анализ решений и разрешение

Интегрированная группировка (только IPPD)

Org. Среда для интеграции (только IPPD)

Интегрированное управление поставщиками (только SS)

Удалось

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

Планирование проекта

Мониторинг и контроль проекта

Управление соглашениями с поставщиками

Измерение и анализ

Обеспечение качества процесса и продукции

Управление конфигурацией

начальный

CMMI — Уровни возможностей

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

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

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

• 0 — незавершенный
• 1 — выполнено
• 2 — Управляемый
• 3 — определено
• 4 — Количественно управляемый
• 5 — Оптимизация

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

Уровень возможностей 0: незавершенный

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

Это равносильно уровню зрелости 1 в поэтапном представлении.

Уровень возможностей 1: Выполнено

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

Уровень возможностей 2: Управляемый

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

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

Уровень возможностей 3: Определен

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

Уровень возможностей 4: Количественно управляемый

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

Уровень возможностей 5: Оптимизация

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

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

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

категория	Область процесса
Управление проектом	Планирование проекта Мониторинг и контроль проекта Управление соглашениями с поставщиками Интегрированное управление проектами (IPPD) Интегрированное управление поставщиками (SS) Интегрированная группировка (IPPD) Управление рисками Количественное управление проектами
Служба поддержки	Управление конфигурацией Обеспечение качества процесса и продукции Измерение и анализ Причинный анализ и разрешение Анализ решений и разрешение Организационная среда для интеграции (IPPD)
инженерия	Управление требованиями Разработка требований Техническое решение Интеграция продуктов верификация Проверка
Управление процессом	Фокус организационного процесса Определение организационного процесса Организационное обучение Эффективность организационного процесса Организационные инновации и развертывание

CMMI — Ключевые области процесса

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

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

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

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

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

• Управление процессом

• Управление проектом

• инженерия

• Служба поддержки

Управление процессом

Управление проектом

инженерия

Служба поддержки

Каждая область процесса определяется набором целей и практик. Есть две категории целей и практик —

• Общие цели и практики — они являются частью каждой области процесса.

• Конкретные цели и практики — они специфичны для данной области процесса.

Общие цели и практики — они являются частью каждой области процесса.

Конкретные цели и практики — они специфичны для данной области процесса.

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

Общие цели и практики

Общие цели и практики являются частью каждой области процесса.

ОБОЗНАЧЕНИЯ — GG -> Общие цели и GP -> Общая практика

• GG 1 Достигнуть определенных целей

  • GP 1.1 Выполнять конкретные практики

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

  • GP 2.1 Установить организационную политику

  • GP 2.2 Планирование процесса

  • GP 2.3 Предоставить ресурсы

  • GP 2.4 назначить ответственность

  • GP 2.5 Train People

  • GP 2.6 Управление конфигурациями

  • GP 2.7 Определение и вовлечение соответствующих заинтересованных сторон

  • GP 2.8 Мониторинг и контроль процесса

  • GP 2.9 Объективно оценить приверженность

  • GP 2.10 Просмотр статуса с управлением высшего уровня

• GG 3 Институционализировать определенный процесс

  • GP 3.1 Установить определенный процесс

  • GP 3.2 Сбор информации об улучшении

• GG 4 Институционализировать количественно управляемый процесс

  • GP 4.1 Установить количественные цели для процесса

  • GP 4.2 Стабилизация производительности подпроцесса

• GG 5 Институционализировать процесс оптимизации

  • GP 5.1 Обеспечить постоянное улучшение процессов

  • GP 5.2 Правильные первопричины проблем

GG 1 Достигнуть определенных целей

GP 1.1 Выполнять конкретные практики

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

GP 2.1 Установить организационную политику

GP 2.2 Планирование процесса

GP 2.3 Предоставить ресурсы

GP 2.4 назначить ответственность

GP 2.5 Train People

GP 2.6 Управление конфигурациями

GP 2.7 Определение и вовлечение соответствующих заинтересованных сторон

GP 2.8 Мониторинг и контроль процесса

GP 2.9 Объективно оценить приверженность

GP 2.10 Просмотр статуса с управлением высшего уровня

GG 3 Институционализировать определенный процесс

GP 3.1 Установить определенный процесс

GP 3.2 Сбор информации об улучшении

GG 4 Институционализировать количественно управляемый процесс

GP 4.1 Установить количественные цели для процесса

GP 4.2 Стабилизация производительности подпроцесса

GG 5 Институционализировать процесс оптимизации

GP 5.1 Обеспечить постоянное улучшение процессов

GP 5.2 Правильные первопричины проблем

Общие черты

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

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

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

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

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

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

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

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

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

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

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

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

Области обработки в деталях

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

Причинный анализ и разрешение

• Это область процесса поддержки на уровне зрелости 5.

Это область процесса поддержки на уровне зрелости 5.

Цель

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

Конкретные практики по целям

• SG 1 определить причины дефектов

  • SP 1.1 Выбор данных дефекта для анализа

  • SP 1.2 Анализ причин

• ИК 2 Адрес Причины дефектов

  • СП 2.1 Внедрить предложения о действиях

  • SP 2.2 Оценка эффекта от изменений

  • SP 2.3 Запись данных

SG 1 определить причины дефектов

SP 1.1 Выбор данных дефекта для анализа

SP 1.2 Анализ причин

ИК 2 Адрес Причины дефектов

СП 2.1 Внедрить предложения о действиях

SP 2.2 Оценка эффекта от изменений

SP 2.3 Запись данных

Управление конфигурацией

• Это область процесса поддержки на уровне зрелости 2.

Это область процесса поддержки на уровне зрелости 2.

Цель

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

Конкретные практики по целям

• ИК 1 устанавливает исходные условия

  • SP 1.1 Определение элементов конфигурации

  • SP 1.2 Создание системы управления конфигурацией

  • SP 1.3 Создание или выпуск базовых показателей

• SG 2 Отслеживание и контроль изменений

  • SP 2.1 Отслеживание запросов на изменение

  • SP 2.2 Элементы конфигурации управления

• ИК 3 Обеспечить честность

  • SP 3.1 Создание записей управления конфигурацией

  • SP 3.2 Выполнить аудит конфигурации

ИК 1 устанавливает исходные условия

SP 1.1 Определение элементов конфигурации

SP 1.2 Создание системы управления конфигурацией

SP 1.3 Создание или выпуск базовых показателей

SG 2 Отслеживание и контроль изменений

SP 2.1 Отслеживание запросов на изменение

SP 2.2 Элементы конфигурации управления

ИК 3 Обеспечить честность

SP 3.1 Создание записей управления конфигурацией

SP 3.2 Выполнить аудит конфигурации

Анализ решений и разрешение

• Это область процесса поддержки на уровне зрелости 3.

Это область процесса поддержки на уровне зрелости 3.

Цель

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

Конкретные практики по целям

• ИК 1 Оценка альтернатив

  • SP 1.1 Установить руководящие принципы для анализа решений

  • SP 1.2 Установить критерии оценки

  • SP 1.3 Определить альтернативные решения

  • SP 1.4 Выбор методов оценки

  • SP 1.5 Оценка альтернатив

  • SP 1.6 Выбор решений

ИК 1 Оценка альтернатив

SP 1.1 Установить руководящие принципы для анализа решений

SP 1.2 Установить критерии оценки

SP 1.3 Определить альтернативные решения

SP 1.4 Выбор методов оценки

SP 1.5 Оценка альтернатив

SP 1.6 Выбор решений

Комплексное управление проектами + IPPD

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

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

Цель

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

Конкретные практики по целям

• ИК 1 Использовать определенный процесс проекта

  • SP 1.1 Установить определенный процесс проекта

  • SP 1.2 Использование активов организационного процесса для планирования деятельности по проекту

  • SP 1.3 Создание рабочей среды проекта

  • SP 1.4 Интегрировать планы

  • SP 1.5 Управление проектом с использованием интегрированных планов

  • SP 1.6 Вклад в организационные процессы Активы

• ИК 2 координирует и сотрудничает с соответствующими заинтересованными сторонами

  • SP 2.1 Управление участием заинтересованных сторон

  • SP 2.2 Управление зависимостями

  • SP 2.3. Решить вопросы координации

ИК 1 Использовать определенный процесс проекта

SP 1.1 Установить определенный процесс проекта

SP 1.2 Использование активов организационного процесса для планирования деятельности по проекту

SP 1.3 Создание рабочей среды проекта

SP 1.4 Интегрировать планы

SP 1.5 Управление проектом с использованием интегрированных планов

SP 1.6 Вклад в организационные процессы Активы

ИК 2 координирует и сотрудничает с соответствующими заинтересованными сторонами

SP 2.1 Управление участием заинтересованных сторон

SP 2.2 Управление зависимостями

SP 2.3. Решить вопросы координации

Добавление IPPD —

• ИК 3 Применить принципы IPPD

  • SP 3.1 Определение общего видения проекта

  • SP 3.2 Создание интегрированной структуры команды

  • SP 3.3 Распределить требования к интегрированным командам

  • SP 3.4 Создание интегрированных команд

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

ИК 3 Применить принципы IPPD

SP 3.1 Определение общего видения проекта

SP 3.2 Создание интегрированной структуры команды

SP 3.3 Распределить требования к интегрированным командам

SP 3.4 Создание интегрированных команд

SP 3.5 Обеспечить сотрудничество между взаимодействующими командами

Измерение и анализ

Это область процесса поддержки на уровне зрелости 2.

Цель

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

Конкретные практики по целям

• ИК 1 Align Измерения и анализ деятельности

  • SP 1.1 Установить цели измерения

  • SP 1.2 Указать меры

  • SP 1.3 Указать процедуры сбора и хранения данных

  • SP 1.4 Указать процедуры анализа

• ИК 2 предоставляет результаты измерений

  • SP 2.1 Сбор данных измерений

  • SP 2.2 Анализ данных измерений

  • SP 2.3 Хранить данные и результаты

  • SP 2.4 сообщить результаты

ИК 1 Align Измерения и анализ деятельности

SP 1.1 Установить цели измерения

SP 1.2 Указать меры

SP 1.3 Указать процедуры сбора и хранения данных

SP 1.4 Указать процедуры анализа

ИК 2 предоставляет результаты измерений

SP 2.1 Сбор данных измерений

SP 2.2 Анализ данных измерений

SP 2.3 Хранить данные и результаты

SP 2.4 сообщить результаты

Организационные инновации и развертывание

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

Цель

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

Конкретные практики по целям

• SG 1 Выберите улучшения

  • SP 1.1 Сбор и анализ предложений по улучшению

  • SP 1.2 Определить и проанализировать инновации

  • SP 1.3 Пилот Усовершенствования

  • SP 1.4 Выбор улучшений для развертывания

• Улучшения в развертывании SG 2

  • SP 2.1 Планирование зон развертывания

  • SP 2.2 Управление развертыванием

  • SP 2.3 Измерение эффектов улучшения

SG 1 Выберите улучшения

SP 1.1 Сбор и анализ предложений по улучшению

SP 1.2 Определить и проанализировать инновации

SP 1.3 Пилот Усовершенствования

SP 1.4 Выбор улучшений для развертывания

Улучшения в развертывании SG 2

SP 2.1 Планирование зон развертывания

SP 2.2 Управление развертыванием

SP 2.3 Измерение эффектов улучшения

Определение организационного процесса + IPPD (OPD)

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

Цель

Целью определения организационного процесса + IPPD (OPD) является создание и поддержка пригодного для использования набора активов организационного процесса.

Конкретные практики по целям

• ИК 1 Создание активов организационного процесса

  • SP 1.1 Установить стандартные процессы

  • SP 1.2 Создание описания модели жизненного цикла

  • SP 1.3 Установить критерии и рекомендации по пошиву

  • SP 1.4 Создать измерительный архив Организации

  • SP 1.5 Создание библиотеки активов процесса организации

ИК 1 Создание активов организационного процесса

SP 1.1 Установить стандартные процессы

SP 1.2 Создание описания модели жизненного цикла

SP 1.3 Установить критерии и рекомендации по пошиву

SP 1.4 Создать измерительный архив Организации

SP 1.5 Создание библиотеки активов процесса организации

Добавление IPPD —

• SG 2 Включить управление IPPD

  • SP 2.1 Создание механизмов расширения прав и возможностей

  • SP 2.2 Установить правила и руководящие указания для интегрированных команд

  • SP 2.3 Balance Team и Обязанности домашней организации

SG 2 Включить управление IPPD

SP 2.1 Создание механизмов расширения прав и возможностей

SP 2.2 Установить правила и руководящие указания для интегрированных команд

SP 2.3 Balance Team и Обязанности домашней организации

Фокус организационного процесса

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

Цель

Целью Фокус Организационного Процесса (OPF) является планирование и реализация усовершенствования организационного процесса на основе глубокого понимания текущих сильных и слабых сторон процессов и активов организации.

Конкретные практики по целям

• ИК 1 Определить возможности улучшения процесса

  • SP 1.1 Определение потребностей организационного процесса

  • SP 1.2 Оценка процессов организации

  • SP 1.3. Определить улучшения в организации

• ИК 2 планирует и осуществляет деятельность по улучшению процесса

  • SP 2.1 Разработка планов действий процесса

  • SP 2.2 Реализация планов действий процесса

• ИК 3 Развертывание активов организационного процесса и включение извлеченных уроков

  • SP 3.1 Развертывание активов организационного процесса

  • SP 3.2 Развертывание стандартных процессов

  • SP 3.3 Мониторинг реализации

  • SP 3.4 Включение опыта, связанного с процессом, в активы организационного процесса

ИК 1 Определить возможности улучшения процесса

SP 1.1 Определение потребностей организационного процесса

SP 1.2 Оценка процессов организации

SP 1.3. Определить улучшения в организации

ИК 2 планирует и осуществляет деятельность по улучшению процесса

SP 2.1 Разработка планов действий процесса

SP 2.2 Реализация планов действий процесса

ИК 3 Развертывание активов организационного процесса и включение извлеченных уроков

SP 3.1 Развертывание активов организационного процесса

SP 3.2 Развертывание стандартных процессов

SP 3.3 Мониторинг реализации

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

Эффективность организационного процесса

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

Цель

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

Конкретные практики по целям

• ИК 1 устанавливает базовые показатели и модели эффективности

  • SP 1.1 Выбор процессов

  • SP 1.2 Установить показатели эффективности процесса

  • SP 1.3 Установить цели качества и производительности процесса

  • SP 1.4 Установить базовые показатели производительности процесса

  • SP 1.5 Создание моделей производительности процесса

ИК 1 устанавливает базовые показатели и модели эффективности

SP 1.1 Выбор процессов

SP 1.2 Установить показатели эффективности процесса

SP 1.3 Установить цели качества и производительности процесса

SP 1.4 Установить базовые показатели производительности процесса

SP 1.5 Создание моделей производительности процесса

Организационное обучение

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

Цель

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

Конкретные практики по целям

• ИК 1 Создание организационного тренинга

  • SP 1.1 Определение стратегических потребностей в обучении

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

  • SP 1.3 Разработка тактического плана организационного обучения

  • SP 1.4 Установить возможности обучения

• ИК 2 Обеспечить необходимое обучение

  • SP 2.1 Провести обучение

  • SP 2.2 Создание учебных записей

  • SP 2.3 Оценка эффективности обучения

ИК 1 Создание организационного тренинга

SP 1.1 Определение стратегических потребностей в обучении

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

SP 1.3 Разработка тактического плана организационного обучения

SP 1.4 Установить возможности обучения

ИК 2 Обеспечить необходимое обучение

SP 2.1 Провести обучение

SP 2.2 Создание учебных записей

SP 2.3 Оценка эффективности обучения

Интеграция продуктов

Это область инженерного процесса на уровне зрелости 3.

Цель

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

Конкретные практики по целям

• ИК 1 Подготовка к интеграции продукта

  • SP 1.1 Определить последовательность интеграции

  • SP 1.2 Создание среды интеграции продукта

  • SP 1.3 Установить процедуры и критерии интеграции продукта

• SG 2 Обеспечить совместимость интерфейса

  • SP 2.1 Обзор описания интерфейса для полноты

  • SP 2.2 Управление интерфейсами

• ИК 3 Собрать компоненты продукта и доставить продукт

  • SP 3.1 Подтвердить готовность компонентов продукта к интеграции

  • SP 3.2 Сборка компонентов продукта

  • SP 3.3 Оценка собранных компонентов продукта

  • SP 3.4 Упаковка и доставка продукта или компонента продукта

ИК 1 Подготовка к интеграции продукта

SP 1.1 Определить последовательность интеграции

SP 1.2 Создание среды интеграции продукта

SP 1.3 Установить процедуры и критерии интеграции продукта

SG 2 Обеспечить совместимость интерфейса

SP 2.1 Обзор описания интерфейса для полноты

SP 2.2 Управление интерфейсами

ИК 3 Собрать компоненты продукта и доставить продукт

SP 3.1 Подтвердить готовность компонентов продукта к интеграции

SP 3.2 Сборка компонентов продукта

SP 3.3 Оценка собранных компонентов продукта

SP 3.4 Упаковка и доставка продукта или компонента продукта

Мониторинг и контроль проекта

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

Цель

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

Конкретные практики по целям

• SG 1 Monitor Project против плана

  • SP 1.1 Мониторинг параметров планирования проекта

  • SP 1.2 Мониторинг обязательств

  • SP 1.3 Мониторинг рисков проекта

  • SP 1.4 Монитор Управление данными

  • SP 1.5 Мониторинг участия заинтересованных сторон

  • SP 1.6 Проводить обзоры прогресса

  • SP 1.7 Провести контрольные оценки

• SG 2 Управление корректирующим действием для закрытия

  • SP 2.1 Анализ проблем

  • SP 2.2 Принять корректирующие меры

  • SP 2.3 Управление корректирующими действиями

SG 1 Monitor Project против плана

SP 1.1 Мониторинг параметров планирования проекта

SP 1.2 Мониторинг обязательств

SP 1.3 Мониторинг рисков проекта

SP 1.4 Монитор Управление данными

SP 1.5 Мониторинг участия заинтересованных сторон

SP 1.6 Проводить обзоры прогресса

SP 1.7 Провести контрольные оценки

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

SP 2.1 Анализ проблем

SP 2.2 Принять корректирующие меры

SP 2.3 Управление корректирующими действиями

Планирование проекта

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

Цель

Целью планирования проекта (ПП) является создание и ведение планов, определяющих деятельность по проекту.

Конкретные практики по целям

• ИК 1 устанавливает оценки

  • SP 1.1 Оценка масштабов проекта

  • SP 1.2 Установить оценки рабочего продукта и атрибутов задачи

  • SP 1.3 Определить жизненный цикл проекта

  • СП 1.4 Определить оценки усилий и затрат

• ИК 2 Разработка плана проекта

  • SP 2.1 Установить бюджет и график

  • SP 2.2 Определение рисков проекта

  • SP 2.3 План управления данными

  • SP 2.4 План ресурсов проекта

  • SP 2.5 План необходимых знаний и навыков

  • SP 2.6 Планирование участия заинтересованных сторон

  • СП 2.7 Разработка плана проекта

• ИК 3 Добиться приверженности плану

  • SP 3.1 Рассмотреть планы, которые влияют на проект

  • SP 3.2 Согласование уровней работы и ресурсов

  • SP 3.3 Получить план обязательств

ИК 1 устанавливает оценки

SP 1.1 Оценка масштабов проекта

SP 1.2 Установить оценки рабочего продукта и атрибутов задачи

SP 1.3 Определить жизненный цикл проекта

СП 1.4 Определить оценки усилий и затрат

ИК 2 Разработка плана проекта

SP 2.1 Установить бюджет и график

SP 2.2 Определение рисков проекта

SP 2.3 План управления данными

SP 2.4 План ресурсов проекта

SP 2.5 План необходимых знаний и навыков

SP 2.6 Планирование участия заинтересованных сторон

СП 2.7 Разработка плана проекта

ИК 3 Добиться приверженности плану

SP 3.1 Рассмотреть планы, которые влияют на проект

SP 3.2 Согласование уровней работы и ресурсов

SP 3.3 Получить план обязательств

Обеспечение качества процесса и продукции

Это область процесса поддержки на уровне зрелости 2.

Цель

Цель обеспечения качества процессов и продуктов (PPQA) — предоставить персоналу и руководству объективное представление о процессах и связанных с ними рабочих продуктах.

Конкретные практики по целям

• ИК 1 Объективно оценивает процессы и рабочие продукты

  • SP 1.1 Объективно оценивать процессы

  • SP 1.2 Объективно оценивать рабочие продукты и услуги

• ИК 2 Обеспечить объективное понимание

  • SP 2.1 Связь и обеспечение решения проблем несоответствия

  • SP 2.2 Установить записи

ИК 1 Объективно оценивает процессы и рабочие продукты

SP 1.1 Объективно оценивать процессы

SP 1.2 Объективно оценивать рабочие продукты и услуги

ИК 2 Обеспечить объективное понимание

SP 2.1 Связь и обеспечение решения проблем несоответствия

SP 2.2 Установить записи

Количественное управление проектами

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

Цель

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

Конкретные практики по целям

• ИК 1 Количественное управление проектом

  • SP 1.1 Установить цели проекта

  • SP 1.2 Составьте определенные процессы

  • SP 1.3 Выбор подпроцессов, которые будут статистически управляться

  • SP 1.4 Управление выполнением проекта

• SG 2 Статистически управлять производительностью подпроцесса

  • SP 2.1 Выбор мер и аналитических методов

  • SP 2.2 Применение статистических методов для понимания изменений

  • SP 2.3 Мониторинг производительности выбранных подпроцессов

  • SP 2.4 Запись статистических данных управления

ИК 1 Количественное управление проектом

SP 1.1 Установить цели проекта

SP 1.2 Составьте определенные процессы

SP 1.3 Выбор подпроцессов, которые будут статистически управляться

SP 1.4 Управление выполнением проекта

SG 2 Статистически управлять производительностью подпроцесса

SP 2.1 Выбор мер и аналитических методов

SP 2.2 Применение статистических методов для понимания изменений

SP 2.3 Мониторинг производительности выбранных подпроцессов

SP 2.4 Запись статистических данных управления

Разработка требований

Это область инженерного процесса на уровне зрелости 3.

Цель

Целью разработки требований (RD) является создание и анализ требований клиентов, продуктов и компонентов продукта.

Конкретные практики по целям

• SG 1 Разработка требований клиента

  • SP 1.1 Выявленные потребности

  • SP 1.2 Разработка требований клиента

• ИК 2 Разработка требований к продукту

  • SP 2.1 Установить требования к продукту и компонентам продукта

  • SP 2.2 Распределить требования к компонентам продукта

  • SP 2.3 Определение требований к интерфейсу

• ИК 3 Анализировать и утверждать требования

  • SP 3.1 Установить операционные концепции и сценарии

  • SP 3.2 Установить определение требуемой функциональности

  • SP 3.3 Анализ требований

  • SP 3.4 Анализ требований для достижения баланса

  • SP 3.5 Проверить требования

SG 1 Разработка требований клиента

SP 1.1 Выявленные потребности

SP 1.2 Разработка требований клиента

ИК 2 Разработка требований к продукту

SP 2.1 Установить требования к продукту и компонентам продукта

SP 2.2 Распределить требования к компонентам продукта

SP 2.3 Определение требований к интерфейсу

ИК 3 Анализировать и утверждать требования

SP 3.1 Установить операционные концепции и сценарии

SP 3.2 Установить определение требуемой функциональности

SP 3.3 Анализ требований

SP 3.4 Анализ требований для достижения баланса

SP 3.5 Проверить требования

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

Это область инженерного процесса на уровне зрелости 2.

Цель

Целью Управления требованиями (REQM) является управление требованиями к продуктам проекта и компонентам продукта и выявление несоответствий между этими требованиями и планами проекта и рабочими продуктами.

Конкретные практики по целям

• SG 1 Управление требованиями

  • SP 1.1 Получить понимание требований

  • SP 1.2 Получить соответствие требованиям

  • SP 1.3 Управление изменениями требований

  • SP 1.4 Поддержка двунаправленной прослеживаемости требований

  • SP 1.5 Определение несоответствий между проектной работой и требованиями

SG 1 Управление требованиями

SP 1.1 Получить понимание требований

SP 1.2 Получить соответствие требованиям

SP 1.3 Управление изменениями требований

SP 1.4 Поддержка двунаправленной прослеживаемости требований

SP 1.5 Определение несоответствий между проектной работой и требованиями

Управление рисками

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

Цель

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

Конкретные практики по целям

• ИК 1 Подготовка к управлению рисками

  • SP 1.1 Определить источники и категории риска

  • SP 1.2 Определение параметров риска

  • SP 1.3 Установить стратегию управления рисками

• ИК 2 Определить и проанализировать риски

  • SP 2.1 Определить риски

  • SP 2.2 Оценка, классификация и определение приоритетов рисков

• SG 3 Смягчить риски

  • SP 3.1 Разработка планов по снижению рисков

  • SP 3.2 Реализация планов по снижению рисков

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

SP 1.1 Определить источники и категории риска

SP 1.2 Определение параметров риска

SP 1.3 Установить стратегию управления рисками

ИК 2 Определить и проанализировать риски

SP 2.1 Определить риски

SP 2.2 Оценка, классификация и определение приоритетов рисков

SG 3 Смягчить риски

SP 3.1 Разработка планов по снижению рисков

SP 3.2 Реализация планов по снижению рисков

Управление соглашениями с поставщиками

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

Цель

Целью Управления соглашениями с поставщиками (SAM) является управление приобретением продуктов у поставщиков, для которых существует официальное соглашение.

Конкретные практики по целям

• ИК 1 устанавливает соглашения с поставщиками

  • SP 1.1 Определить тип приобретения

  • SP 1.2 Выбор поставщиков

  • SP 1.3 Создание соглашений с поставщиками

• SG 2 удовлетворяет соглашения с поставщиками

  • SP 2.1 Оформить Соглашение с поставщиком

  • SP 2.2 Мониторинг выбранных процессов поставщика

  • SP 2.3 Оценка выбранных продуктов работы поставщика

  • SP 2.4 Принять приобретенный продукт

  • SP 2.5 Переходные продукты

ИК 1 устанавливает соглашения с поставщиками

SP 1.1 Определить тип приобретения

SP 1.2 Выбор поставщиков

SP 1.3 Создание соглашений с поставщиками

SG 2 удовлетворяет соглашения с поставщиками

SP 2.1 Оформить Соглашение с поставщиком

SP 2.2 Мониторинг выбранных процессов поставщика

SP 2.3 Оценка выбранных продуктов работы поставщика

SP 2.4 Принять приобретенный продукт

SP 2.5 Переходные продукты

Техническое решение

Это область инженерного процесса на уровне зрелости 3.

Цель

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

Конкретные практики по целям

• SG 1 Выберите продукт-компонент решения

  • SP 1.1 Разработка альтернативных решений и критериев выбора

  • SP 1.2 Выбор компонентов продукта Решения

• SG 2 Разработка дизайна

  • SP 2.1 Разработка продукта или компонента продукта

  • SP 2.2 Создание пакета технических данных

  • SP 2.3 Разработка интерфейсов с использованием критериев

  • SP 2.4 Выполнить анализ Make, Buy или Reuse

• ИК 3 Внедрить дизайн продукта

  • SP 3.1 Реализация дизайна

  • SP 3.2 Разработка документации по поддержке продукта

SG 1 Выберите продукт-компонент решения

SP 1.1 Разработка альтернативных решений и критериев выбора

SP 1.2 Выбор компонентов продукта Решения

SG 2 Разработка дизайна

SP 2.1 Разработка продукта или компонента продукта

SP 2.2 Создание пакета технических данных

SP 2.3 Разработка интерфейсов с использованием критериев

SP 2.4 Выполнить анализ Make, Buy или Reuse

ИК 3 Внедрить дизайн продукта

SP 3.1 Реализация дизайна

SP 3.2 Разработка документации по поддержке продукта

Проверка

Это область инженерного процесса на уровне зрелости 3.

Цель

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

Конкретные практики по целям

• ИК 1 Подготовка к проверке

  • SP 1.1 Выбор продуктов для проверки

  • SP 1.2 Создание среды валидации

  • SP 1.3 Установить процедуры и критерии валидации

• SG 2 Проверка продукта или компонентов продукта

  • SP 2.1 Выполнить валидацию

  • SP 2.2 Анализ результатов валидации.

ИК 1 Подготовка к проверке

SP 1.1 Выбор продуктов для проверки

SP 1.2 Создание среды валидации

SP 1.3 Установить процедуры и критерии валидации

SG 2 Проверка продукта или компонентов продукта

SP 2.1 Выполнить валидацию

SP 2.2 Анализ результатов валидации.

верификация

Это область инженерного процесса на уровне зрелости 3.

Цель

Цель проверки (VER) — убедиться, что выбранные рабочие продукты соответствуют указанным требованиям.

Конкретные практики по целям

• ИК 1 Подготовиться к проверке

  • SP 1.1 Выбор рабочих продуктов для проверки

  • SP 1.2 Создание среды проверки

  • SP 1.3 Установить процедуры и критерии проверки

• SG 2 Выполнить экспертные оценки

  • SP 2.1 Подготовка к экспертной оценке

  • SP 2.2 Проводить экспертные оценки

  • SP 2.3 Анализ данных экспертной оценки

• ИК 3 Проверка выбранных рабочих продуктов

  • SP 3.1 Выполнить проверку

  • SP 3.2 Анализ результатов проверки

ИК 1 Подготовиться к проверке

SP 1.1 Выбор рабочих продуктов для проверки

SP 1.2 Создание среды проверки

SP 1.3 Установить процедуры и критерии проверки

SG 2 Выполнить экспертные оценки

SP 2.1 Подготовка к экспертной оценке

SP 2.2 Проводить экспертные оценки

SP 2.3 Анализ данных экспертной оценки

ИК 3 Проверка выбранных рабочих продуктов

SP 3.1 Выполнить проверку

SP 3.2 Анализ результатов проверки

Изменения, сделанные в версии 1.2

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

• Следующие области процесса были удалены (все на уровне зрелости 3) —

  • Организационная среда для интеграции (OEI)

  • Интегрированный Teaming (IT)

  • Интегрированное управление поставщиками (ISM)

• Следующие дополнения были внесены в существующие области процессов —

  • IPM. SG3 и SG4 были исключены, был добавлен новый SG3 (все PA IPPD)

  • OPD. SG был добавлен, превратив его в PA IPPD

  • БКП два SP были извлечены из SG и создали SG3 вместе с двумя новыми SP

  • REQD SP3.5 был переименован в Validate Requirements

  • СЭМ. SP2.1 был исключен, два новых SP добавлены в SG2

  • TS. SP1.2 был устранен

  • VER. SP3.2 был переименован Анализ результатов проверки

Следующие области процесса были удалены (все на уровне зрелости 3) —

Организационная среда для интеграции (OEI)

Интегрированный Teaming (IT)

Интегрированное управление поставщиками (ISM)

Следующие дополнения были внесены в существующие области процессов —

IPM. SG3 и SG4 были исключены, был добавлен новый SG3 (все PA IPPD)

OPD. SG был добавлен, превратив его в PA IPPD

БКП два SP были извлечены из SG и создали SG3 вместе с двумя новыми SP

REQD SP3.5 был переименован в Validate Requirements

СЭМ. SP2.1 был исключен, два новых SP добавлены в SG2

TS. SP1.2 был устранен

VER. SP3.2 был переименован Анализ результатов проверки

CMMI — Оценки

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

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

Оценки учитывают три категории компонентов модели, как определено в CMMI —

• Обязательно — только конкретные и общие цели.

• Ожидаемые — только конкретные и общие практики.

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

Обязательно — только конкретные и общие цели.

Ожидаемые — только конкретные и общие практики.

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

ГЭИ выпустила два руководящих документа для оценки CMMI —

• Требования к оценке для CMMI (ARC). Содержит требования для трех классов методов оценки: класса A, класса B и класса C. Эти требования являются правилами для определения каждого класса метода оценки.

• Стандартный метод оценки CMMI для улучшения процесса (SCAMPI) — Описание метода Документ (MDD) в настоящее время является единственным утвержденным методом оценки класса А.

Требования к оценке для CMMI (ARC). Содержит требования для трех классов методов оценки: класса A, класса B и класса C. Эти требования являются правилами для определения каждого класса метода оценки.

Стандартный метод оценки CMMI для улучшения процесса (SCAMPI) — Описание метода Документ (MDD) в настоящее время является единственным утвержденным методом оценки класса А.

В настоящее время SCAMPI является единственным утвержденным методом оценки CMMI класса А. То есть SCAMPI удовлетворяет всем требованиям метода оценки ARC класса A и был одобрен SEI.

Существует три класса методов оценки CMMI: класс A, класс B и класс C.

SCAMPI Оценка класса A

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

Вы можете ожидать следующих результатов от SCAMPI A —

• Рейтинг уровня зрелости или рейтинг возможностей.

• Выводы, которые описывают сильные и слабые стороны процесса вашей организации по отношению к CMMI.

• Консенсус по ключевым вопросам организации процесса.

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

Рейтинг уровня зрелости или рейтинг возможностей.

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

Консенсус по ключевым вопросам организации процесса.

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

SCAMPI Оценка класса B

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

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

Вы можете ожидать следующих результатов от SCAMPI B —

• Подробные выводы, которые описывают сильные и слабые стороны процесса вашей организации по отношению к CMMI.

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

• Консенсус по ключевым вопросам организации процесса.

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

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

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

Консенсус по ключевым вопросам организации процесса.

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

SCAMPI Оценка класса C

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

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

• Обеспечить быстрый анализ пробелов в процессе организации относительно CMMI.

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

• Контролировать реализацию процесса.

• Определить готовность организации к SCAMPI A.

• Поддержать выбор поставщика.

Обеспечить быстрый анализ пробелов в процессе организации относительно CMMI.

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

Контролировать реализацию процесса.

Определить готовность организации к SCAMPI A.

Поддержать выбор поставщика.

Вы можете ожидать следующих результатов от SCAMPI C —

• Результаты, которые описывают сильные и слабые стороны оцениваемых процессов. В зависимости от области оценки и стратегии результаты могут быть сопоставлены с соответствующими компонентами CMMI.

• Характеристики, которые суммируют адекватность оцененных процессов по отношению к CMMI.

• Рекомендуемые действия по улучшению процесса.

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

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

Характеристики, которые суммируют адекватность оцененных процессов по отношению к CMMI.

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

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

Характеристики класса оценки

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

Характеристики	Класс А	Класс б	Класс С
Количество собранных объективных доказательств	Высоко	Средняя	Низкий
Рейтинг создан	да	нет	нет
Потребности в ресурсах	Высоко	Средняя	Низкий
Размер команды	большой	Средняя	Маленький
Источники данных (инструменты, интервью и документы)	Требуются все три источника данных	Требуется только два источника данных (один должен быть интервью)	Требуется только один источник данных
Требование к руководителю оценочной группы	Авторизованный ведущий оценщик	Уполномоченный ведущий оценщик или лицо, обученное и опытное	Человек обученный и опытный

Основы SCAMPI

SCAMPI — это сокращение, обозначающее Стандартный метод оценки CMMI для улучшения процессов. Оценка SCAMPI должна проводиться уполномоченным SEI ведущим оценщиком SCAMPI. SCAMPI поддерживается набором продуктов SCAMPI, который включает в себя описание метода SCAMPI, вопросник по зрелости, рабочие пособия и шаблоны.

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

SCAMPI основан на опыте предыдущих методов, в том числе —

• CBA IPI — CMM-оценка для улучшения внутренних процессов.

• SCE — Оценка возможностей программного обеспечения.

• EIA / IS 732.2 — Временный международный стандарт, озаглавленный «Метод оценки системной инженерии».

• SDCE — Оценка возможностей разработки программного обеспечения.

• Метод оценки ФАУ.

CBA IPI — CMM-оценка для улучшения внутренних процессов.

SCE — Оценка возможностей программного обеспечения.

EIA / IS 732.2 — Временный международный стандарт, озаглавленный «Метод оценки системной инженерии».

SDCE — Оценка возможностей разработки программного обеспечения.

Метод оценки ФАУ.

CMMI Игроки — Роли Обязанности

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

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

Улучшение процесса

Усилия по улучшению процесса обычно требуют следующих лиц и групп —

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

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

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

• Члены EPG. Эти лица входят в состав EPG в качестве членов комитета. Они несут ответственность за то, чтобы документация по улучшению процесса была написана и соблюдалась. Они также несут ответственность за создание метрик для отслеживания процесса улучшения процесса. Они ведут ПАТ.

• Команды действий процессов (PAT). Эти группы создают документацию по улучшению процессов, политики, процессы, процедуры, уставы и планы действий.

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

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

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

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

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

Команды действий процессов (PAT). Эти группы создают документацию по улучшению процессов, политики, процессы, процедуры, уставы и планы действий.

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

CMMI — Резюме

В этом руководстве описана структура CMMI, состоящая из следующих компонентов:

• Уровни зрелости (поэтапное представление) или Уровни возможностей (непрерывное представление)
• Области деятельности
• Цели: общие и конкретные
• Общие черты
• Практики: общие и специфические

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

Позже мы кратко познакомили вас с оценками CMMI и показали разные классы оценки.

Что дальше?

SEI CMMI — это большой предмет, который нельзя объяснить в небольшом учебнике. Поэтому мы настоятельно рекомендуем вам ознакомиться с другими ресурсами CMMI и собрать больше информации на эту тему. Эти ресурсы перечислены в главе Ресурсы CMMI.

Пожалуйста, пришлите мне свой отзыв на [email protected]

CMMI — Глоссарий

	В	С	D	Е	F	г	ЧАС	я	J	К
L	M	N	О	п	Q	р	S	T	U	В
W	Икс	Y	Z

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

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

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

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

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

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

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

Продвинутые практики — в непрерывном представлении все конкретные практики с уровнем возможностей два или выше.

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

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

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

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

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

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

Оценка оценки — Как используется в оценочных материалах CMMI, значение, присваиваемое группой оценки либо (1) цели CMMI или области процесса, (2) уровню возможностей области процесса или (3) уровню зрелости организации Блок. Рейтинг определяется путем принятия определенного процесса оценки для используемого метода оценки.

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

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

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

Уместно — см. Определение «Адекватно».

По мере необходимости — см. Определение Adequate.

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

Назначаемая причина изменения процесса — В CMMI термин «особая причина изменения процесса» используется вместо «назначаемой причины изменения процесса» для обеспечения согласованности. Оба термина определены одинаково.

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

Базовая мера — отдельное свойство или характеристика объекта и метод его количественной оценки.

Базовые практики — В непрерывном представлении все конкретные практики с уровнем возможностей 1.

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

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

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

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

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

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

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

Причинный анализ — анализ дефектов для определения их причины.

Управление изменениями — разумное использование средств для изменения или предлагаемого изменения продукта или услуги.

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

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

Адаптация модели CMMI — использование подмножества модели CMMI с целью сделать ее подходящей для конкретного применения. Целью адаптации модели является помощь организации в согласовании применения модели с ее бизнес-целями.

CMMI Product Suite — этот термин использовался для полной CMMI Framework.

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

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

Концепция операций — общее описание того, каким образом объект используется или действует.

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

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

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

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

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

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

Управление конфигурацией — дисциплина, применяющая технические и административные указания и надзор для (1) идентификации и документирования функциональных и физических характеристик элемента конфигурации, (2) контроля изменений этих характеристик, (3) записи и отчета об изменении состояния обработки и реализации, и (4) проверить соответствие указанным требованиям. [IEEE Std 610.1990]

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

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

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

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

COTS — Товары, которые можно приобрести у коммерческого продавца.

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

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

Плотность дефектов — количество дефектов на единицу размера продукта (например, отчеты о проблемах на 1000 строк кода).

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

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

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

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

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

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

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

Усиление дисциплины. Компоненты модели, которые обеспечивают руководство для интерпретации информации о модели для определенных дисциплин (например, системная инженерия или разработка программного обеспечения), называются «УСИЛЕНИЯ ДЛЯ ДИСЦИПЛИНЫ». Дисциплинарные усиления добавляются к другим компонентам модели, где это необходимо. Их легко найти, потому что они появляются в правой части страницы и имеют заголовок, указывающий дисциплину, к которой они обращаются (например, «Для разработки программного обеспечения»).

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

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

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

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

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

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

Обнаружение — см. Результаты оценки.

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

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

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

Общая цель — ОБЩИЕ ЦЕЛИ называются «общими», потому что одна и та же формулировка цели появляется в нескольких областях процесса. В поэтапном представлении каждая область процесса имеет только одну общую цель. Достижение общей цели в области процесса означает улучшение контроля при планировании и реализации процессов, связанных с этой областью процесса, что указывает на то, могут ли эти процессы быть эффективными, повторяемыми и продолжительными. Общие цели являются обязательными компонентами модели и используются в оценках для определения того, удовлетворяется ли область процесса.

Общая практика — ОБЩИЕ ПРАКТИКИ обеспечивают институционализацию, чтобы гарантировать, что процессы, связанные с областью процессов, будут эффективными, повторяемыми и длительными. Общие практики классифицируются по общим целям и общим характеристикам и являются ожидаемыми компонентами в моделях CMMI. (В областях процесса отображаются только общее название практики, утверждение и разработки.)

Разработка общей практики — После конкретных практик появляются названия и утверждения общей практики, которые относятся к области процесса. После каждого общего практического заявления разработка может появляться в виде простого текста с заголовком «Разработка». РАЗРАБОТКА ОБЩЕЙ ПРАКТИКИ предоставляет информацию о том, как следует интерпретировать общую практику для области процесса. Если нет никакой разработки, применение общей практики очевидно без разработки.

Цель — «ЦЕЛЬ» — это обязательный компонент CMMI, который может быть общей или конкретной целью. Когда вы видите слово «цель» в модели CMMI, оно всегда относится к компонентам модели (например, общая цель, конкретная цель).

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

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

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

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

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

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

Управление интерфейсом — В управлении конфигурацией процесс (1) идентификации всех функциональных и физических характеристик, относящихся к взаимодействию двух или более элементов конфигурации, предоставленных одной или несколькими организациями, и (2) обеспечения оценки предлагаемых изменений этих характеристик и одобрен до внедрения. [IEEE 828-1983].

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

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

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

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

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

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

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

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

Цель — термин цель используется в CMMI в обычном повседневном смысле; это наша цель или цель, которая будет достигнута.

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

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

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

Операционная концепция — общее описание того, каким образом объект используется или работает.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Определение процесса — Акт определения и описания процесса. Результатом определения процесса является описание процесса.

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

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

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

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

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

План улучшения процесса — в области процесса «Фокус организационного процесса» см. Определение «плана улучшения процесса» во вводных примечаниях.

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

Владелец процесса — лицо (или группа), ответственное за определение и ведение процесса. На организационном уровне владельцем процесса является лицо (или группа), ответственное за описание стандартного процесса; на уровне проекта владельцем процесса является лицо (или группа), ответственное за описание определенного процесса. Поэтому процесс может иметь несколько владельцев на разных уровнях ответственности.

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

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

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

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

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

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

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

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

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

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

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

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

Требования к продукту — уточнение требований заказчика на языке разработчиков, превращение неявных требований в явные производные требования.

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

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

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

Процесс, определенный проектом — В области процесса Интегрированное управление проектом см. Определение «Процесс, определенный проектом», во вступительных примечаниях и в конкретной практике «Установление процесса, определенного проектом».

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

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

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

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

Количественная цель — желаемое целевое значение, выраженное в количественных показателях.

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

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

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

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

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

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

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

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

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

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

Анализ рисков — оценка, классификация и определение приоритетов рисков.

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

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

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

Основная причина — первопричина является источником дефекта, так что, если он устранен, дефект уменьшается или удаляется.

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

Разработка программного обеспечения — (1) Применение системного, дисциплинированного, количественного подхода к разработке, эксплуатации и обслуживанию программного обеспечения. (2) Изучение подходов как в (1).

Приглашение — процесс подготовки пакета запроса и выбора поставщика (подрядчика).

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

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

Конкретная цель — КОНКРЕТНЫЕ ЦЕЛИ применяются к области процесса и касаются уникальных характеристик, которые описывают то, что должно быть реализовано для удовлетворения области процесса. Конкретные цели являются обязательными компонентами модели и используются в оценках, чтобы помочь определить, удовлетворена ли область процесса.

Конкретная практика — КОНКРЕТНАЯ ПРАКТИКА — это деятельность, которая считается важной для достижения соответствующей конкретной цели. Конкретные практики описывают действия, которые, как ожидается, приведут к достижению конкретных целей области процесса. Конкретные практики являются ожидаемыми компонентами модели.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обучение — в области «Организационное обучение» см. Определение .training. во вступительных замечаниях.

Модульное тестирование — Тестирование отдельных аппаратных или программных модулей или групп связанных модулей.

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

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

Проверка реализации — общая особенность областей процессов модели CMMI с поэтапным представлением, которая группирует общие практики, связанные с проверкой руководством более высокого уровня, и объективной оценкой соответствия описаниям процессов, процедурам и стандартам.

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

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

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

Рабочий продукт . Термин « Рабочий продукт» используется во всем наборе продуктов CMMI для обозначения любого артефакта, созданного процессом. Эти артефакты могут включать файлы, документы, части продукта, услуги, процессы, спецификации и счета. Примеры процессов, которые следует рассматривать как рабочие продукты, включают производственный процесс, процесс обучения и процесс утилизации продукта. Ключевое различие между РАБОЧИМ ПРОДУКТОМ и компонентом продукта заключается в том, что рабочий продукт не должен проектироваться или являться частью конечного продукта.

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

CMMI — Сокращения

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