Интеграция модели зрелости возможностей

Интеграция модели зрелости возможностей ( CMMI ) — это программа обучения и оценки улучшения уровня процесса. Администрируемая Институтом CMMI , дочерней компанией ISACA , она была разработана в Университете Карнеги-Меллона (CMU). Она требуется многими правительственными контрактами США, особенно в области разработки программного обеспечения . CMU утверждает, что CMMI может использоваться для руководства улучшением процесса в рамках проекта, подразделения или всей организации.

CMMI определяет следующие пять уровней зрелости (от 1 до 5) для процессов: начальный, управляемый, определенный, количественно управляемый и оптимизирующий. Версия CMMI 3.0 была опубликована в 2023 году; ^[1] Версия 2.0 была опубликована в 2018 году; Версия 1.3 была опубликована в 2010 году и является эталонной моделью для остальной информации в этой статье. CMMI зарегистрирована в Патентном и товарном бюро США CMU. ^[2]

Первоначально CMMI охватывал три области интересов:

1. Разработка продуктов и услуг – CMMI для развития (CMMI-DEV),
2. Создание и управление услугами – CMMI для услуг (CMMI-SVC) и
3. Приобретение продуктов и услуг – CMMI для приобретения (CMMI-ACQ).

В версии 2.0 эти три области (ранее имевшие отдельную модель для каждой) были объединены в одну модель.

CMMI была разработана группой представителей промышленности, правительства и Института программной инженерии (SEI) в CMU. Модели CMMI предоставляют руководство по разработке или улучшению процессов, которые соответствуют бизнес-целям организации. Модель CMMI также может использоваться в качестве основы для оценки зрелости процессов организации. ^[3] К январю 2013 года весь набор продуктов CMMI был передан из SEI в Институт CMMI, недавно созданную организацию в Карнеги-Меллоне. ^[4]

CMMI был разработан в рамках проекта CMMI, целью которого было улучшить удобство использования моделей зрелости путем интеграции множества различных моделей в одну структуру. Проект состоял из представителей промышленности, правительства и Института программной инженерии Карнеги-Меллона (SEI). Основными спонсорами были Управление министра обороны ( OSD ) и Национальная оборонно-промышленная ассоциация .

CMMI является преемником модели зрелости возможностей (CMM) или Software CMM. CMM разрабатывалась с 1987 по 1997 год. В 2002 году была выпущена версия 1.1, в августе 2006 года последовала версия 1.2, а в ноябре 2010 года — версия 1.3. Некоторые основные изменения в CMMI V1.3 ^[5] включают поддержку гибкой разработки программного обеспечения , ^[6] улучшения в практиках высокой зрелости ^[7] и выравнивание представления (поэтапное и непрерывное). ^[8]

По данным Института программной инженерии (SEI, 2008), CMMI помогает «интегрировать традиционно отдельные организационные функции, устанавливать цели и приоритеты улучшения процессов, предоставлять руководство для качественных процессов и предоставлять точку отсчета для оценки текущих процессов». ^[9]

Мэри Бет Криссис, Майк Конрад и Сэнди Шрам Роудон были авторской группой для публикации печатной версии CMMI for Development Version 1.2 и 1.3. Публикация Addison-Wesley версии 1.3 была посвящена памяти Уоттса Хамфри. Эйлин К. Форрестер, Брэндон Л. Буто и Сэнди Шрам были авторской группой для публикации печатной версии CMMI for Services Version 1.3. Роудон «Расти» Янг был главным архитектором разработки версии CMMI 2.0. Ранее он был владельцем продукта CMMI и руководителем отдела качества SCAMPI в Институте программной инженерии.

В марте 2016 года Институт CMMI был приобретен ISACA .

В апреле 2023 года был выпущен CMMI V3.0.

В версии 1.3 CMMI существовал в двух представлениях: непрерывном и поэтапном. ^[3] Непрерывное представление разработано для того, чтобы позволить пользователю сосредоточиться на конкретных процессах, которые считаются важными для непосредственных бизнес-целей организации, или тех, которым организация присваивает высокую степень риска. Поэтапное представление разработано для предоставления стандартной последовательности улучшений и может служить основой для сравнения зрелости различных проектов и организаций. Поэтапное представление также обеспечивает легкую миграцию из SW-CMM в CMMI. ^[3]

В версии 2.0 указанное выше разделение представлений было отменено, и теперь существует только одна связная модель. ^[10]

В зависимости от используемых областей интереса (приобретение, услуги, разработка) области процессов, которые он содержит, будут различаться. ^[11] Области процессов — это области, которые будут охвачены процессами организации. В таблице ниже перечислены семнадцать основных областей процессов CMMI, которые присутствуют для всех областей интереса CMMI в версии 1.3.

Ниже перечислены области процессов и уровни их зрелости для модели CMMI для услуг:

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

• CM – Управление конфигурацией
• МА – Измерение и анализ
• PPQA – Процесс и обеспечение качества
• REQM – Управление требованиями
• SAM – Управление соглашениями с поставщиками
• SD – Предоставление услуг
• WMC – Мониторинг и контроль работы
• WP – Планирование работы

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

• CAM – Управление мощностью и доступностью
• DAR – Анализ и разрешение решений
• IRP – Разрешение и предотвращение инцидентов
• IWM – Интегрированное управление работой
• OPD – Определение организационного процесса
• OPF – Фокус на организационном процессе...
• ОТ – Организационное обучение
• РСКМ – Управление рисками
• SCON – Непрерывность обслуживания
• SSD – Разработка сервисной системы
• SST – Переход системы обслуживания
• STSM – Стратегическое управление услугами

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

• OPP – Эффективность организационных процессов
• QWM – Количественное управление работой

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

• CAR – Причинно-следственный анализ и разрешение.
• OPM – Управление эффективностью организации.

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

• CMMI for Development (CMMI-DEV), версия 1.3 была выпущена в ноябре 2010 года. Она охватывает процессы разработки продуктов и услуг.
• CMMI for Acquisition (CMMI-ACQ), версия 1.3 была выпущена в ноябре 2010 года. Она охватывает процессы управления цепочками поставок, закупок и аутсорсинга в государственном секторе и промышленности.
• CMMI for Services (CMMI-SVC), версия 1.3 была выпущена в ноябре 2010 года. Она содержит рекомендации по предоставлению услуг внутри организации и внешним клиентам.

В версии 2.0 DEV, ACQ и SVC были объединены в единую модель, где каждая область процесса потенциально имеет конкретную ссылку на один или несколько из этих трех аспектов. Пытаясь идти в ногу с отраслью, модель также имеет явную ссылку на agile-аспекты в некоторых областях процесса.

Ниже приведены некоторые ключевые различия между моделями v1.3 и v2.0:

1. «Области процесса» были заменены на «Области практики (PA)». Последние организованы по уровням, а не по «Конкретным целям».
2. Каждый PA состоит из «ядра» [т. е. общего и свободного от терминологии описания] и «контекстно-зависимого» [т. е. описания с точки зрения Agile/Scrum, разработки, услуг и т. д.] раздела.
3. Поскольку все практики теперь обязательны к соблюдению, раздел «Ожидаемое» был удален.
4. «Общие практики» были включены в новую область под названием «Инфраструктура управления и внедрения», а «Конкретные практики» были исключены.
5. Особое внимание следует уделять обеспечению внедрения ПА и их постоянной практике до тех пор, пока они не станут «привычкой».
6. Все уровни зрелости ориентированы на ключевое слово «результативность».
7. Включены два и пять дополнительных PA из сферы «Безопасность» и «Защита».
8. Области процесса PCMM были объединены.

Организация не может быть сертифицирована в CMMI; вместо этого организация оценивается . В зависимости от типа оценки, организация может быть удостоена рейтинга уровня зрелости (1–5) или профиля достижений уровня возможностей.

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

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

Оценки организаций, использующих модель CMMI ^[12], должны соответствовать требованиям, определенным в документе «Требования к оценке для CMMI (ARC)». Существует три класса оценок: A, B и C, которые фокусируются на выявлении возможностей для улучшения и сравнении процессов организации с передовой практикой CMMI. Из них оценка класса A является наиболее формальной и единственной, которая может привести к рейтингу уровня. Оценочные группы используют модель CMMI и метод оценки, соответствующий ARC, для руководства своей оценкой организации и составления отчетов о выводах. Затем результаты оценки могут использоваться (например, группой процессов) для планирования улучшений для организации.

Стандартный метод оценки CMMI для улучшения процессов (SCAMPI) — это метод оценки, который соответствует всем требованиям ARC. ^[13] Результаты оценки SCAMPI могут быть опубликованы (с одобрения оцениваемой организации) на веб-сайте CMMI SEI: Опубликованные результаты оценки SCAMPI. SCAMPI также поддерживает проведение оценок ISO/IEC 15504 , также известных как SPICE (Software Process Improvement and Capability Determination), и т. д.

Этот подход способствует тому, чтобы члены EPG и PAT были обучены CMMI, чтобы была проведена неформальная оценка (SCAMPI C) и чтобы области процессов были приоритетными для улучшения. Более современные подходы, которые включают развертывание коммерчески доступных, совместимых с CMMI процессов, могут значительно сократить время достижения соответствия. SEI ведет статистику по «времени перехода» для организаций, принявших более раннюю версию Software CMM, а также CMMI. ^[14] Эти статистические данные показывают, что с 1987 года медианное время перехода с уровня 1 на уровень 2 составляет 23 месяца, а с уровня 2 на уровень 3 — еще 20 месяцев. С момента выпуска CMMI медианное время перехода с уровня 1 на уровень 2 составляет 5 месяцев, а медианное перемещение на уровень 3 — еще 21 месяц. Эти статистические данные обновляются и публикуются каждые шесть месяцев в профиле зрелости. ^{[ требуется ссылка ]}

Методология командного программного процесса Института инженерии программного обеспечения (SEI) и использование моделей CMMI могут быть использованы для повышения уровня зрелости. Новый продукт под названием Accelerated Improvement Method ^[15] (AIM) объединяет использование CMMI и TSP. ^[16]

Для решения проблем безопасности пользователей доступны два неофициальных руководства по безопасности. Considering the Case for Security Content в CMMI for Services имеет одну область процесса, Security Management. ^[17] Security by Design с CMMI for Development, Version 1.3 имеет следующие области процесса:

• OPSD – Организационная готовность к безопасному развитию
• SMP – Безопасное управление проектами
• SRTS – Требования безопасности и технические решения
• SVV – Проверка и подтверждение безопасности

Хотя они не влияют на уровни зрелости или возможностей, эти области процесса могут быть отражены в результатах оценки. ^[18]

SEI опубликовал исследование, в котором говорится, что 60 организаций измерили рост производительности в категориях затрат, графика, производительности, качества и удовлетворенности клиентов. ^[19] Медианное увеличение производительности варьировалось от 14% (удовлетворенность клиентов) до 62% (производительность). Однако модель CMMI в основном касается того, какие процессы должны быть внедрены, а не того , как они могут быть внедрены. Эти результаты не гарантируют, что применение CMMI повысит производительность в каждой организации. Небольшая компания с небольшими ресурсами может с меньшей вероятностью извлечь выгоду из CMMI; эта точка зрения подтверждается профилем зрелости процесса (стр. 10). Из небольших организаций (<25 сотрудников) 70,5% оцениваются на уровне 2: Управляемые, в то время как 52,8% организаций с 1001–2000 сотрудников оцениваются на самом высоком уровне (5: Оптимизирующие).

Turner & Jain (2002) утверждают, что, хотя очевидно, что существуют большие различия между CMMI и гибкой разработкой программного обеспечения , оба подхода имеют много общего. Они считают, что ни один из способов не является «правильным» способом разработки программного обеспечения, но что есть фазы в проекте, где один из двух подходит лучше. Они предлагают объединить различные фрагменты методов в новый гибридный метод. Sutherland et al. (2007) утверждают, что сочетание Scrum и CMMI обеспечивает большую адаптивность и предсказуемость, чем каждый из них по отдельности. ^[20] David J. Anderson (2005) дает подсказки о том, как интерпретировать CMMI в гибкой манере. ^[21]

Дорожные карты CMMI ^[22] , которые представляют собой целевой подход к выбору и развертыванию соответствующих областей процесса из модели CMMI-DEV, могут предоставить руководство и фокус для эффективного внедрения CMMI. Существует несколько дорожных карт CMMI для непрерывного представления, каждая из которых имеет определенный набор целей по улучшению. Примерами являются дорожная карта проекта CMMI ^[23] , дорожные карты продукта и интеграции продукта CMMI ^[24] и дорожные карты процессов и измерений CMMI. ^[25] Эти дорожные карты сочетают в себе сильные стороны как поэтапного, так и непрерывного представления.

Было описано сочетание метода управления проектами, управления заработанной стоимостью (EVM), с CMMI. ^[26] В заключение, аналогичное использование CMMI, экстремальное программирование ( XP ), метод разработки программного обеспечения, было оценено с CMM/CMMI (Nawrocki et al., 2002). Например, подход к управлению требованиями XP, который опирается на устное общение, был оценен как не соответствующий CMMI.

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

• Модель незрелости возможностей
• Модель зрелости возможностей
• Структура оценки архитектуры предприятия
• LeanCMMI
• Модель зрелости человеческих возможностей
• Группа процессов разработки программного обеспечения

На Викискладе есть медиафайлы по теме Интеграция модели зрелости возможностей .

• Официальный сайт