Что такое CMMI

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

Хотя этот семинар не о методологии, он о CMMI, а эта модель является скорее набором критериев, чем методологией.

У этого конспекта есть и еще одно отличие от предыдущих. Его подготовил не я.

Я благодарю Алену Федосееву за разрешение опубликовать этот материал в моём блоге.

Оглавление

Что такое СММ

Что такое CMMI

Поэтапный подход

Непрерывный подход

Пример применения CMMI

Определения

Процессные области (Process Area)

Что такое СММ

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

То есть:

1. проблемы с качеством результата

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

Результатом работы SEI (Института системного инжиниринга при Университете Карнеги-Меллона) стало появление модели CMM (Capability Maturity Model) для разработки программного обеспечения (версия 0.6 была опубликована в 1990 г., версия 1.0 – в 1991 г., версия 2 – в 1997 году).

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

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

Что такое CMMI

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

- модель зрелости процессов разработки программного обеспечения (Capability Maturity Model for Software – SW-CMM)
- модель зрелости процессов для системного реинжиниринга (Electronic Industries Alliance Interim Standard – EIA/IS 731)
- модель зрелости процессов интегрированной разработки продуктов (Integrated Product Development Capability Maturity Model – IPD-CMM)

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

Поэтапный подход

В CMM на соответствие уровню зрелости оценивались ВСЕ процессы организации. Если представлять это диаграммой, то это выглядит следующим образом:

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

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

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

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

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

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

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

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

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

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

Непрерывный подход

CMMI предоставляет 2 подхода – 2 модели:

1. поэтапная репрезентация, унаследованная от CMM

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

На диаграмме это выглядит следующим образом:

При внедрении CMMI на непрерывной основе порядок улучшения процессных областей не фиксирован. Качество процессов в каждой процессной области может быть оценено на один из шести (0-5) уровней устойчивости (capability level).

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

Разумеется, большинство крупных IT-компаний выбирают именно поэтапное представление. Получив уровень повыше, можно аргументированно объяснять клиенту почему эта компания предпочтительнее, чем компания-конкурент. Однако трудоемкость на проекте, который использует CMMI модель, как минимум увеличивается на 10%-20%.

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

Пример применения CMMI

Определения

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

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

Практики (practices) – это действия, производимые для достижения поставленных целей в данной области процессов.

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

Специфические цели (specific goals) – цели, конкретизирующие основную (общую) цель

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

Специфические практики (specific practices) – практики, выполнение которых способствует достижению специфических целей.

Общие практики (generic practices) – практики, выполнение которых способствует достижению общих целей.

Субпрактики (subpractices) – представляют собой детализированные описания, поясняющие специфические и общие практики.

Процессные области (Process Area)

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

Уровень	Описание	Процессные области
5 Оптимизирующий	Continuous Process Improvement	Organizational Innovation and Deployment Causal Analysis and Resolution
4 Количественно управляемый (измеримый)	Quantitative Management	Organizational Process Performance Quantitative Project Management
3 Определенный	Process Standardization	Requirements Development Technical Solution Product Integration Verification Validation Organizational Process Focus Organizational Process Definition Organizational Training Integrated Project Management for IPPD Risk Management Integrated Teaming Integrated Supplier Management Decision Analysis and Resolution Organizational Environment for Integration
2 Управляемый	Basic Project Management	Requirements Management Project Planning Project Monitoring and Control Supplier Agreement Management Measurement and Analysis Process and Product Quality Assurance Configuration Management
1 Начальный

Вот типичный пример описания специальной цели для процессной области Requirements Management:

SG 1: Requirements are managed and inconsistencies with project plans and work products are identified.

А вот описание специальной практики:

SP 1.3: Manage Requirements Changes. Manage changes to the requirements as they evolve during the project.

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

GG2: The process is institutionalized as a managed process.

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

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

GP 2.1: Establish an Organizational Policy

Establish and maintain an organizational policy for planning and performing appropriate process.

GP 2.2: Plan the Process

Establish and maintain the plan for performing appropriate process.

GP 2.3: Provide Resources

Provide adequate resources for performing appropriate process, developing the work products, and providing the services of the process.

GP 2.4: Assign Responsibility

Assign responsibility and authority for performing the process, developing the work products, and providing the services of appropriate process.

GP 2.5: Train People

Train the people performing or supporting appropriate process as needed.

GP 2.6: Manage Configurations

Place designated work products of appropriate process under appropriate levels of configuration management.

GP 2.7: Identify and Involve Relevant Stakeholders

Identify and involve the relevant stakeholders of appropriate process as planned.

GP 2.8: Monitor and Control the Process

Monitor and control appropriate process against the plan for performing the process and take appropriate corrective action.

GP 2.9: Objectively Evaluate Adherence

Objectively evaluate adherence of appropriate process against its process description, standards, and procedures, and address non-compliance.

GP 2.10: Review Status with Higher Level Management

Review the activities, status, and results of appropriate process with higher level management and resolve issues.