Capability Maturity Model

Capability Maturity Model (CMM) — это методология (модель) оценки и совершенствования процессов разработки программного обеспечения и других видов деятельности, описывающая эволюционные уровни зрелости процессов организации. Разработана в 1986—1993 годах в Институте программной инженерии (SEI) Университета Карнеги — Меллон по заказу Министерства обороны США. Модель представляет собой набор принципов и практик, позволяющих организации систематически повышать качество, предсказуемость и управляемость своих процессов.

История

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

В 1980-х годах Министерство обороны США столкнулось с систематическими срывами сроков, превышением бюджетов и низким качеством при заказе крупных программных проектов у подрядчиков. Отсутствие стандартизированных критериев оценки поставщиков приводило к тому, что заказчики не могли объективно сравнивать компетенции разных компаний. В 1986 году Институт программной инженерии (SEI) начал разработку инструмента для оценки зрелости процессов разработки ПО.

Разработка и первые версии

Первая версия CMM (CMM for Software, SW-CMM) была опубликована в 1991 году. Она базировалась на работах Уоттса Хамфри, Филипа Кросби и Эдварда Деминга. В 1993 году вышла версия 1.1, ставшая наиболее распространённой. Модель быстро получила распространение в оборонной промышленности США, а затем — в коммерческом секторе, особенно в компаниях, работающих с государственными заказами.

Эволюция в CMMI

В 2000-х годах SEI разработал интеграционную модель CMMI (Capability Maturity Model Integration), объединившую несколько разрозненных моделей CMM (для ПО, системной инженерии, управления персоналом и др.). CMMI стала более гибкой и универсальной, поддерживая два представления: ступенчатое (staged) — для оценки уровня зрелости организации, и непрерывное (continuous) — для оценки зрелости отдельных процессов. Последняя версия CMMI 2.0 вышла в 2018 году.

Структура и уровни зрелости

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

Уровень 1: Начальный (Initial)

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

Уровень 2: Повторяемый (Repeatable)

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

Уровень 3: Определённый (Defined)

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

Уровень 4: Управляемый (Managed)

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

Уровень 5: Оптимизирующий (Optimizing)

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

Ключевые области процессов (KPA)

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

Уровень 2: KPA

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

Уровень 3: KPA

• Фокус на процессах организации
• Определение процессов организации
• Программа обучения
• Интегрированное управление проектом
• Разработка продукта
• Межгрупповая координация
• Экспертные обзоры (peer reviews)

Уровень 4: KPA

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

Уровень 5: KPA

• Предотвращение дефектов
• Управление изменениями технологий
• Управление изменениями процессов

Применение

Разработка программного обеспечения

CMM изначально создавалась для оценки зрелости процессов разработки ПО. Организации, достигшие уровней 4 и 5, демонстрируют существенно более низкий уровень дефектов, более предсказуемые сроки и бюджеты. Многие государственные контракты США (особенно оборонные) требовали от подрядчиков наличия сертификации на уровне 3 и выше.

Другие отрасли

Модель CMM и её преемник CMMI применяются в системной инженерии, управлении проектами, разработке аппаратного обеспечения, финансовом секторе, здравоохранении и государственном управлении. Например, CMMI for Services используется для оценки зрелости процессов предоставления услуг, CMMI for Acquisition — для процессов закупок и аутсорсинга.

В России

В России модель CMM/CMMI получила распространение в крупных IT-компаниях, работающих с зарубежными заказчиками, а также в оборонно-промышленном комплексе. Российские компании, такие как «Лаборатория Касперского», «1С» и ряд аутсорсинговых разработчиков, проходили оценку на уровни 3 и 4. Однако с 2022 года в связи с санкционными ограничениями и уходом западных аудиторов количество официальных оценок CMMI в России резко сократилось. Альтернативой стали российские стандарты ГОСТ Р ИСО/МЭК 12207 и ГОСТ Р 57193.

Критика и ограничения

Бюрократизация

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

Негибкость

Традиционная CMM (до появления CMMI) была жёстко привязана к каскадной модели разработки и плохо сочеталась с гибкими методологиями (Agile, Scrum). Позднее CMMI была адаптирована для работы с Agile, но критика сохраняется: модель ориентирована на крупные организации с формализованными процессами и плохо подходит для стартапов и небольших команд.

Сложность внедрения

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

Культурные различия

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

Интересные факты

• Первая организация, достигшая уровня 5 по CMM, — Motorola (1993 год).
• По данным SEI, к 2010 году сертификацию CMMI прошли более 10 000 организаций по всему миру.
• Модель CMM стала основой для создания других моделей зрелости, включая People CMM (управление персоналом), Software Acquisition CMM (закупки ПО) и COBIT (управление IT).
• В 2017 году SEI передал управление CMMI консорциуму ISACA (Information Systems Audit and Control Association), что сделало модель более открытой и доступной для коммерческого сектора.

Источники:

• Humphrey, W. S. (1989). Managing the Software Process. Addison-Wesley.
• Paulk, M. C., et al. (1993). Capability Maturity Model for Software, Version 1.1. SEI Technical Report CMU/SEI-93-TR-024.
• Chrissis, M. B., Konrad, M., & Shrum, S. (2011). CMMI for Development: Guidelines for Process Integration and Product Improvement. Addison-Wesley.
• ГОСТ Р ИСО/МЭК 12207-2010. Информационная технология. Процессы жизненного цикла программных средств.
• SEI. (2018). CMMI Model Version 2.0. Carnegie Mellon University.