Комплексная модель производительности и зрелости (CMMI — Capability Maturity Model Integration)

Краткое описание из википедии

Capability Maturity Model Integration (CMMI) — набор моделей (методологий) совершенствования процессов в организациях разных размеров и видов деятельности. CMMI содержит набор рекомендаций в виде практик, реализация которых, по мнению разработчиков модели, позволяет реализовать цели, необходимые для полной реализации определенных областей деятельности.

Набор моделей CMMI включает три модели: CMMI for Development (CMMI-DEV), CMMI for Services (CMMI-SVC) и CMMI for Acquisition (CMMI-ACQ). Наиболее известной является модель CMMI for Development, ориентированная на организации, занимающиеся разработкой программного обеспечения, аппаратного обеспечения, а также комплексных систем. Все действующие версии моделей имеют номер 1.2. Модель CMMI-DEV была опубликована в августе 2006 года, CMMI-ACQ — в ноябре 2007-го, CMMI-SVC — в феврале 2009-го.

CMMI является развитием методологии CMM, которая разрабатывалась со второй половины 1980-х годов Software Engineering Institute (SEI) в университете Карнеги-Меллона (Carnegie Mellon University).

А теперь подробнее…

Предпосылки к созданию

Модель CMMI изначально разрабатывалась для того, чтобы выявить те практики, использование которых при разработке ПО позволяло получать качественные системы в срок и в рамках запланированных бюджетов. Для выявления этих практик на протяжение вот уже более 30 лет выполняется анализ ключевых активностей, выполняемых при разработке ПО, и связанных с ними рисков. Анализируются как best practices – практики, которые позволили успешно избежать или смягчить тот или иной риск, так и worst practices – типичные ошибки, совершение которых приводит к проблемам в качестве, срыву сроков и превышению бюджетов. В самой модели все активности сгруппированы в т.н. процессные области, которые в свою очередь могут быть сгруппированы по уровням зрелости, характеризующие уровень зрелости организации в целом.

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

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

История возникновения и развития. Текущее состояние.

История создания CMMI (а более точно, тогда еще ее прародительницы – CMM) уходит корнями в середину 80-х годов прошлого столетия. Тогда, министерство обороны США, обеспокоенное большим количеством неудачных проектов, вызванных проблемами в ПО, а также непредсказуемостью появления таких проблем, решило найти способ повысить вероятность получения качественного ПО от своих многочисленных вендоров. Типичные проблемы, от которых страдало МО США были такого плана: запустили новую ракету, а она из-за сбоя в ПО вместо учебной мишени перенацелилась на гражданский самолет и успешно его поразила (общественный резонанс, финансовые потери). Или в спутнике, запущенном к неблизкой планете солнечной системы типа Венеры, из-за ошибки в ПО была неправильно рассчитана скорость снижения и он на огромной скорости врезался в поверхность, похоронив инвестиции и результаты многолетней работы по его созданию и обеспечению полета до цели (финансовые потери, упущенные возможности).

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

Итак, качество и стабильность этого качества. И возможность оценивать вендоров ПО по этим критериям.
В 1986 году на деньги МО США к исследованию этой задачи преступает SEI – Software Engineering Institute, созданный на базе Carnegie Mellon University. Работы начинаются не с чистого листа. В 1979 году Philip B. Crosby опубликовал свою “знаковую” книгу Quality is Free, в которой предложил матрицу зрелости организаций — Quality Management Maturity Grid (QMMG). В ней впервые появились пять уровней зрелости, которые тогда выглядели следующим образом:

• Uncertainty
• Awakening
• Enlightment
• Wisdom
• Certainty

Кроме матрицы QMMG на момент начала работ SEI была также опубликована работа сотрудников IBM R. A. Radice, J. T. Harding и др. “A Programming Process Study” (IBM Systems Journal Vol. 24, No.2, 1985), которая содержала описание IBM Maturity Grid со своими 5 уровнями, своими атрибутами и своими подпроцессами процесса разработки ПО.

Первые результаты SEI появились буквально через год после начала работ. В июне 1987 года вышел технический отчет W.S. Humphrey “Characterizing the Software Process: A Maturity Framework” (CMU/SEI-87-TR-11), который давал ответ на первый основной вопрос, а в сентябре 1987 вышел технический отчет W.S. Humphrey и W. L. Sweet “A Method for Assessing the Software Engineering Capability of Contractors” (CMU/SEI-87-TR-23), который адресовал второй основной вопрос.
Именно в докладе “Characterizing the Software Process: A Maturity Framework” было предложено те 5 уровней зрелости, которые впоследствии были положены в основу CMM:

• Initial
• Repeatable
• Defined
• Managed
• Optimized

Итак, в 1987 году модель по сути являлась опросником с 85 процессными и 16 технологическими вопросами и 5 уровнями зрелости, но при этом не было четких правил, которые позволяли однозначно оценивать уровень зрелости организаций.
Для исправления этой проблемы в 1988 году SEI разработал первый двухчасовой тренинг для команд оценщиков (Software Capability Evaluation — SCE Teams). Также в 1988-1989 годах выполняются работы по нормализации модели и приданию уровням зрелости бОльшей осмысленности, бОльшей независимости и бОльшей непротиворечивости.

В 1989 году выходит книга W. S. Humphrey “Managing the Software Process”. В составе практик областей зрелости происходят некоторые изменения. В январе 1990 года появился первый публичный драфт модели CMM – CMM v0.2. Вместе с выходом v0.2 появляются новые изменения в составе практик уровней зрелости. Директором программы Software Process Program пока еще является Watts Humphrey, но он уже назначил своего преемника – Bill Curtis.

В июне 1990 года выходит один из последних драфтов модели – CMMI v0.6. Проектом руководит уже Bill Curtis. Именно эта версия отразила принятое в непростых дебатах решение о том, что ключевые области практик (key process areas) должны быть полностью “привязаны” к определенному уровню зрелости, а не “пронизывать” модель, по разному проявляясь на разных уровнях.

И, наконец, в августе 1991 года появляется релиз – M. C. Paulk, B. Curtis, M.B. Chrissis “Capability Maturity Model for Software” (CMU/SEI-91-TR-24) и C. V. Weber, M. C. Paulk и др. “Key Practices of the Capability Maturity Model” (CMU/SEI-91-TR-25). Это уже 500-страничный документ.

Модель начинает свое распространение по всему миру. В 1991 году выходит CMM v1.1. Внешне модель не претерпела существенных изменений, но тем ни менее, практически все практики были переработаны и уточнены. Некоторые практики были специально переработаны для поддержки maintenance проектов.
Вот что представляла собой модель CMM v1.1 образца 1991 года:
Level 5 – Optimizing

• Defect Prevention
• Technology Change Management
• Process Change Management

Level 4 – Managed

• Quantitative Process Management
• Software Quality Management

Level 3 – Defined

• Organizational Process Focus
• Organizational Process Definition
• Training Program
• Integrated Software Management
• Software Product Engineering
• Intergroup Coordination
• Peer Review

Level 2 – Managed

• Requirements Management
• Software Project Planning
• Software Project Tracking & Oversight
• Software Subcontract Management
• Software Quality Assurance
• Software Configuration Management

Level 1 — Repeatable

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

Выход CMM v1.1 удачно совпал с началом глобализации и зарождением международного рынка аутсорсинга разработки ПО, поэтому ей было суждено завоевать всеобщее признание и стать де-факто стандартом оценивания зрелости компаний – производителей ПО. А впоследствии – основой для создания модели CMMI.
Модель CMM v1.1 триумфально распространялась по миру. Накапливалась практика применения модели. За несколько лет после выхода модели накопилось значительное количество запросов на изменение. Выполнялись работы по маппированию модели на существовавшие в тот момент времени другие стандарты, относящиеся к разработке ПО. Накапливался фидбэк от крупных организаций, выбравших модель в качестве основы для совершенствования своих процессов разработки.

Началась работа над новой версией модели. Основными задачами новой версии было исправить замеченные неточности и ошибки, вобрать и отразить опыт применения модели, уточнить понимание высших уровней зрелости, минимизировать различия модели с существующими стандартами и выполнить для них мэппинг. Релиз новой версии планировалось закончить к ноябрю 1997 года.
В то же время ставшую популярной модель начали адаптировать для применения в тех областях, для которых изначально модель применять не планировалось. Появились “клоны” модели для system engineering (SE-CMMI), people (PM-CMM), software acquisition (SA-CMM), engineering (engineering maturity model — EMM).

Так же развивались близкие по духу стандартны ISO, такие как ISO 9001, 12207, 15288, наконец, ISO 15504, более известный как SPICE (1995).
В октябре 1997 года ключевой спонсор SEI из министерства обороны США принял решение свернуть работы над второй версией модели CMM ради разработки интегрированной модели CMM – CMM Integration. На момент окончания работ описание второй версии CMM было представлено документом CMM v2C.

Что же было положено в основу CMM Integration?

• Capability Maturity Model for Software V2 draft C (SW CMM v2c)
• EIA Interim Standard 731, System Engineering Capability Model (SECM)
• Integrated Product Development Capability Maturity Model draft v0.98 (IPD-CMM)
• Software Acquisition Capability Maturity Model (SA-CMM)

Вот какие наиболее существенные изменения произошли в модели при переходе от CMM к CMMI.
Level 2

• появилась процессная область Measurement & Analysis.

Level 3

• из области Integrated Software management была выделена отдельная область Risk Management
• область Software Product Engineering была расщеплена на отдельные Requirements Development, Technical Solution, Product Integration, Validation.
• область Peer Reviews трансформировалась в область Validation, вобрав в себя также часть практик Software Product Engineering.
• из модели SE-CMM была добавлена область Decision Analysis & Resolution

Level 4

• была выполнена перегруппировка практик, области были переименованы из Quantitative Process Management в Organizational Proсess Performance, а Software Quality Management в Quantitative Project Management.

Level 5

• Область Defect Prevention была переименована в Causal Analysis and Resolution, а области Technology Change Management и Process Change Management объединены в одну область Organizational Innovation and Deployment.

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

Первая публичная версия CMMI — CMMI v1.02 была опубликована в ноябре 2000 года. Именно тогда появилось разделение модели на “редакции” (SE/SW/IPPD).

Наконец, в декабре 2001 вышла CMMI v1.1 — версия, которой было суждено быть официальной версией SEI CMMI до августа 2006 года.

Структура и содержание модели CMMI

CMMI определяет 22 процессные области (process areas). Для каждой из процессных областей существует ряд целей (goals), которые должны быть достигнуты при внедрении CMMI в данной процессной области. Некоторые цели являются уникальными — они называются специальными (specific). Общие (generic) цели применяются к нескольким процессным областям. Цели достигаются при помощи выполнения практик; так же, как цели, практики делятся на специальные и общие.

Существуют два представления CMMI: непрерывное (continuous) и ступенчатое (staged). При внедрении CMMI на непрерывной основе порядок улучшения процессных областей не фиксирован. Качество процессов в каждой процессной области может быть оценено на один из шести (0-5) уровней производительности (capability level). Ступенчатое представление определяет пять (1-5) уровней зрелости (maturity level) организации. Для достижения каждого уровня зрелости (кроме первого) необходимо выполнить требования по внедрению определённых процессных областей и достижению соответствующих целей.

Уровень 1 – Начальный (Initial)
• Систематический подход к разработке ПО отсутствует.
Уровень 2 – Управляемый (Managed)
• Процессы существуют (описаны и используются) на уровне проектов
• Управление осуществляется в виде реакции на полученные результаты
• Уже используются некоторые «вспомогательные» процессы (Support Category): конфигурационное управление, обеспечение качества рабочих продуктов/процессов
Цель: Базовое проектное управление.
Набор процессных областей второго уровня зрелости
• Process Management
o Нет областей для данного уровня
• Project Management
o Планирование проекта (Project Planning)
o Наблюдение за проектом и контроль (Project Monitoring and Control)
o Управление договоренности с поставщиками (Supplier Agreement Management)
• Engineering
o Управление требованиями (Requirements Management)
• Support
o Управление конфигурациями (Configuration Management)
o Измерения и анализ (Measurement and Analysis)
o Проверка процессов и продуктов на соответствие стандартам (Process and Product Quality Assurance)
Уровень 3 – Определенный (Defined)
• Процессы существуют (описаны и используются) на уровне организации
• Управление осуществляется проактивно
Цель: Стандартизация процессов.
Набор процессных областей третьего уровня зрелости
• Используются все процессные области и общие практики уровня 2
• Process Management
o Определение процессов организации (Organizational Process Focus)
o Organizational Process Definition +IPPD
o Организация обучения (Organizational Training)
• Project Management
o Управление рисками (Risk Management)
o Комплексное управление проектом (Integrated Project Management) + IPPD
• Engineering
o Разработка требований (Requirements Development)
o Техническое решение (Technical Solution)
o Сборка и поставка продукта (Product Integration)
o Проверка продукта на соответствие требованиям (Verification)
o Проверка продукта на соответствие своему предназначению (Validation)
• Support
o Принятие решений и оценка альтернатив (Decision Analysis and Resolution)
Уровень 4 – Управляемый количественно (Quantitatively Managed)
• Процессы измеряются и контролируются
• Управление осуществляется на основании объективно полученных и получаемых данных
Цель: Количественное управление
Набор процессных областей четвертого уровня зрелости
• Все процессные области предыдущих уровней
• Process Management
o Установление показателей выполнения процессов организации (Organizational Process Performance)
• Project Management
o Управление проектами на основе количественных данных (Quantitative Project Management)
Уровень 5 – Оптимизирующийся (Optimizing)
• Процессы постоянно совершенствуются
• Данные о возможных улучшениях собираются и используются
Цель: Непрерывное совершенствование.
Набор процессных областей пятого уровня зрелости
• Все процессные области предыдущих уровней
• Process Management
o Отбор и внедрение улучшений в организации (Organizational Innovation and Deployment)
• Support
o Анализ причин возникновения проблем и предотвращение их появления в будущем (Causal Analysis and Resolution)