CMMI-DEV. Процессные области

Записаться

Место CMMI-DEV среди моделей CMMI

Первая модель из комплекта моделей CMMI, которую мы рассмотрим, — CMMI для разработки (CMMI for Development, CMMI-DEV). Она во многом наследует модель зрелости процессов (Capability Maturity Model, CMM). С неё удобно начать, чтобы почувствовать переход от CMM к семейству CMMI.

Процессные области и их количество

Процессная область (process area) — это аналог группы ключевых процессов в CMM. В CMMI-DEV перечислены 22 процессные области. Запоминать и анализировать все их не нужно. Для примера рассмотрим одну область, связанную с качеством. Это позволит сравнить подходы к обеспечению качества в ранее изученном стандарте и в CMMI-DEV.

Четыре категории процессных областей

Все процессные области CMMI-DEV разбиты на четыре категории:

• Управление процессами (Process Management);
• Управление проектами (Project Management);
• Инжиниринг (Engineering);
• Поддержка (Support).

Самая понятная категория — управление проектами. В ней встречаются знакомые термины: планирование проекта (Project Planning), мониторинг и контроль проекта (Project Monitoring and Control), управление рисками (Risk Management) и другие.

Категория инжиниринг объединяет практики, связанные с разработкой, проектированием и созданием программного продукта.

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

Почему CMMI-DEV не ограничивается программным обеспечением

Важно, что область называется инжиниринг, а не программный инжиниринг. CMMI выросла из CMM, но не ограничивается только разработкой программного обеспечения. По замыслу авторов она может применяться в любом бизнесе и в любой области, связанной с проектированием и разработкой продуктов или услуг, в большей степени продуктов. Поэтому явных ссылок на программное обеспечение нет. Такие термины, как интеграция продукта (Product Integration), разработка требований (Requirements Development), техническое решение (Technical Solution), являются достаточно общими.

Зачем выделены категории

Категории выделены по двум причинам.

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

Во-вторых, категории полезны потому, что разные модели CMMI — например, CMMI для услуг (CMMI for Services, CMMI-SVC) и CMMI для приобретения (CMMI for Acquisition, CMMI-ACQ) — пересекаются по многим процессным областям и целым категориям. Поэтому многие процессные области переходят из одной модели в другую.

Категория «Управление процессами»

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

Категория «Управление проектами»

Управление проектами — самая понятная категория. Она включает:

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

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

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

Категория «Инжиниринг»

Инжиниринг включает:

• сборку продукта;
• разработку требований;
• техническое решение задач;
• валидацию и верификацию.

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

Категория «Поддержка»

Поддержка — самая неопределённая категория. В неё сведено всё, что не удалось отнести к остальным трём областям. Здесь находятся:

• управление конфигурациями;
• измерение и анализ;
• анализ причин и разрешение проблем;
• обеспечение качества процессов и продуктов (Process and Product Quality Assurance).

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

Краткие итоги

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