Войти
Интеграция модели зрелости возможностей (CMMI ) - это программа обучения и оценки повышения уровня процесса. Под управлением Института CMMI, дочерней компании ISACA, он был разработан в Университете Карнеги-Меллона (CMU). Это требуется по многим государственным контрактам США, особенно в разработке программного обеспечения. CMU утверждает, что CMMI можно использовать для улучшения процессов в рамках проекта, подразделения или всей организации. CMMI определяет следующие уровни зрелости процессов: начальный, управляемый, определенный, количественно управляемый и оптимизирующий. Версия 2.0 была опубликована в 2018 году (версия 1.3 была опубликована в 2010 году и является эталонной моделью для остальной информации в этой вики-статье). CMMI зарегистрирован в Управлении по патентам и товарным знакам США CMU.
Характеристики уровней зрелости. Первоначально CMMI рассматривает три области интересов:
В версии 2.0 эти три области (каждая из которых ранее имела отдельную модель) были объединены в одну модель.
CMMI был разработан группой представителей промышленности, правительства и Института программной инженерии (SEI) в CMU. Модели CMMI служат руководством для разработки или улучшения процессов, отвечающих бизнес-целям организации. Модель CMMI также может использоваться в качестве основы для оценки зрелости процессов в организации. К январю 2013 года весь пакет продуктов CMMI был передан из SEI в CMMI Institute, недавно созданную организацию в Карнеги-Меллон.
CMMI был разработан в рамках проекта CMMI, цель которого для повышения удобства использования моделей зрелости путем интеграции множества различных моделей в одну структуру. В проекте участвовали представители отрасли, правительства и Института разработки программного обеспечения Карнеги-Меллона (SEI). Основными спонсорами были канцелярия министра обороны (OSD ) и Национальная оборонная промышленная ассоциация.
CMMI - преемник модели зрелости возможностей (CMM). или программное обеспечение CMM. CMM разрабатывалась с 1987 по 1997 год. В 2002 году была выпущена версия 1.1, за ней последовала версия 1.2 в августе 2006 года и версия 1.3 в ноябре 2010 года. Некоторые важные изменения в CMMI V1.3 касаются поддержки гибкой разработки программного обеспечения, усовершенствования практик высокой зрелости и согласования представления (поэтапного и непрерывного).
Согласно Software Engineering Institute (SEI, 2008), CMMI помогает «интегрировать традиционно отдельные организационные функции, устанавливают цели и приоритеты улучшения процессов, обеспечивают руководство по процессам качества и служат ориентиром для оценки текущих процессов ».
В марте 2016 года Институт CMMI был приобретен ISACA.
В версии 1.3 CMMI существовал в двух представлениях: непрерывном и поэтапном. Непрерывное представление предназначено для того, чтобы позволить пользователю сосредоточиться на конкретных процессах, которые считаются важными для непосредственных бизнес-целей организации или тех, которым организация приписывает высокую степень рисков. Поэтапное представление предназначено для обеспечения стандартной последовательности улучшений и может служить основой для сравнения зрелости различных проектов и организаций. Поэтапное представление также обеспечивает простой переход с SW-CMM на CMMI.
В версии 2.0 вышеупомянутое разделение представлений было отменено, и теперь существует только одна связная модель.
В зависимости от используемых областей интересов (приобретение, услуги, разработка), содержащиеся в ней области процессов будут различаться. Области процессов - это области это будет охвачено процессами организации. В таблице ниже перечислены семнадцать основных областей процессов CMMI, которые присутствуют для всех областей CMMI, представляющих интерес в версии 1.3.
| Аббревиатура | Область процесса | Категория | Уровень зрелости |
|---|---|---|---|
| CAR | Причинно-следственный анализ и решение | Поддержка | 5 |
| CM | Управление конфигурацией | Поддержка | 2 |
| DAR | Анализ решений и разрешение | Поддержка | 3 |
| IPM | Интегрированное управление проектами | Управление проектами | 3 |
| MA | Измерение и анализ | Поддержка | 2 |
| OPD | Определение организационного процесса | Управление процессами | 3 |
| OPF | Фокус организационного процесса | Управление процессами | 3 |
| OPM | Управление производительностью организации | Управление процессами | 5 |
| OPP | Производительность организационных процессов | Управление процессами | 4 |
| OT | Организационное обучение | Управление процессами | 3 |
| PMC | Мониторинг и контроль проектов | Управление проектами | 2 |
| PP | Планирование проекта | Управление проектами | 2 |
| PPQA | Обеспечение качества процессов и продуктов | Поддержка | 2 |
| QPM | Количественный P Управление проектами | Управление проектами | 4 |
| REQM | Управление требованиями | Управление проектами | 2 |
| RSKM | Управление рисками | Управление проектами | 3 |
| SAM | Управление соглашениями с поставщиками | Поддержка | 2 |
Области процессов ниже и их уровни зрелости перечислены для модели CMMI для сервисов:
Уровень зрелости 2 - Управляемый
уровень зрелости 3 - определен
Уровень зрелости 4 - Количественное управление
Уровень зрелости 5 - Оптимизация
Лучшие практики CMMI публикуются в документах, называемых моделями, каждый из которых касается отдельной области интересов. Версия 1.3 предоставляет модели для трех областей интересов: разработка, приобретение и услуги.
В версии 2.0 DEV, ACQ и SVC были объединены в единую модель, где каждая область процесса потенциально имеет конкретную ссылку на один или несколько из этих трех аспектов. Пытаясь не отставать от отрасли, модель также явно ссылается на гибкие аспекты в некоторых областях процессов.
Некоторые ключевые различия между моделями v1.3 и v2.0 приведены ниже; это далеко не полный список.
Организация не может быть сертифицирована в CMMI; вместо этого оценивается организация. В зависимости от типа оценки организации может быть присвоен рейтинг уровня зрелости (1–5) или профиль достижения уровня способностей.
Многие организации ценят измерение своего прогресса путем проведения аттестации. Как правило, аттестация проводится по одной или нескольким из следующих причин:
Оценка организаций, использующих модель CMMI, должна соответствовать требованиям, определенным в Требованиях к оценке для CMMI ( ARC) документ. Существует три класса оценок, A, B и C, которые сосредоточены на выявлении возможностей улучшения и сравнении процессов организации с передовыми практиками CMMI. Из них оценка класса А является наиболее формальной и единственной, которая может привести к присвоению рейтинга уровня. Группы аттестации используют модель CMMI и метод оценки, соответствующий ARC, для управления своей оценкой организации и составлением отчетов о выводах. Затем результаты оценки могут быть использованы (например, группой процессов) для планирования улучшений в организации.
Стандартный метод оценки CMMI для улучшения процесса (SCAMPI) - это метод оценки, который соответствует всем требованиям ARC. Результаты оценки SCAMPI могут быть опубликованы (если оцениваемая организация одобрит) на веб-сайте CMMI SEI: Опубликованные результаты оценки SCAMPI. SCAMPI также поддерживает выполнение ISO / IEC 15504, также известного как SPICE (Улучшение программного процесса и определение возможностей), оценки и т. Д.
Этот подход способствует тому, что участники EPG и PAT должны быть обучены в CMMI, чтобы была проведена неофициальная оценка (SCAMPI C) и чтобы области процессов были приоритетными для улучшения. Более современные подходы, которые включают развертывание коммерчески доступных, совместимых с CMMI процессов, могут значительно сократить время на достижение соответствия. SEI ведет статистику «пора продвигаться» для организаций, принявших более раннюю программную CMM, а также CMMI. Эти статистические данные показывают, что с 1987 года среднее время перехода с уровня 1 на уровень 2 составляет 23 месяца, а с уровня 2 на уровень 3 - еще 20 месяцев. С момента выпуска CMMI среднее время перехода с Уровня 1 на Уровень 2 составляет 5 месяцев, а среднее время перехода на Уровень 3 - еще 21 месяц. Эти статистические данные обновляются и публикуются каждые шесть месяцев в профиле зрелости.
Для повышения уровня зрелости можно использовать методологию командных процессов разработки программного обеспечения (SEI) и использование моделей CMMI. Новый продукт под названием Accelerated Improvement Method (AIM) сочетает в себе использование CMMI и TSP.
Для решения проблем безопасности пользователей доступны два неофициальных руководства по безопасности. При рассмотрении аргументов в пользу безопасности в CMMI for Services есть одна область процессов - Управление безопасностью. Безопасность по дизайну с CMMI для разработки, версия 1.3 имеет следующие области процессов:
Хотя они не влияют на уровни зрелости или возможностей, эти области процессов могут быть указаны в результатах оценки.
SEI опубликовала исследование, в котором говорится, что 60 организаций измерили рост производительности по категориям затрат, графика, производительности, качества и удовлетворенности клиентов. Среднее увеличение производительности варьировалось от 14% (удовлетворенность клиентов) до 62% (производительность). Однако модель CMMI в основном касается того, какие процессы должны быть реализованы, а не столько того, как они могут быть реализованы. Эти результаты не гарантируют, что применение CMMI повысит производительность в каждой организации. Небольшая компания с небольшими ресурсами может с меньшей вероятностью получить выгоду от CMMI; это представление поддерживается профилем зрелости процесса (стр. 10). Что касается небольших организаций (<25 employees), 70.5% are assessed at level 2: Managed, while 52.8% of the organizations with 1,001–2,000 employees are rated at the highest level (5: Optimizing).
Turner Jain (2002)), утверждают, что, хотя очевидны большие различия между CMMI и гибкой разработкой программного обеспечения, у обоих подходов много общего. «правильный» способ разработки программного обеспечения, но в проекте есть этапы, на которых один из двух лучше подходит. Они предлагают объединить различные фрагменты методов в новый гибридный метод. Сазерленд и др. (2007) утверждают что сочетание Scrum и CMMI обеспечивает большую адаптируемость и предсказуемость, чем любой из них по отдельности. Дэвид Дж. Андерсон (2005) дает советы о том, как интерпретировать CMMI гибким способом.
Дорожные карты CMMI, которые представляют собой ориентированный на цели подход к выбору и развертыванию соответствующих областей процессов из модели CMMI-DEV, могут служить руководством и фокусом для эффективного внедрения CMMI.Существует несколько дорожных карт CMMI для непрерывного представления, каждая с конкретным набором целей улучшения. Примеры: CMMI Pro Дорожная карта проекта, Дорожные карты продуктов CMMI и интеграции продуктов и Дорожные карты процессов и измерений CMMI. Эти дорожные карты сочетают в себе сильные стороны как поэтапного, так и непрерывного представления.
Была описана комбинация техники управления проектами управления освоенной стоимостью (EVM) с CMMI (Solomon, 2002 ). В заключение с аналогичным использованием CMMI, Экстремальное программирование (XP ), метод разработки программного обеспечения, был оценен с помощью CMM / CMMI (Nawrocki et al., 2002). Например, подход к управлению требованиями XP, основанный на устном общении, был оценен как несовместимый с CMMI.
CMMI можно оценить, используя два разных подхода: поэтапный и непрерывный. Поэтапный подход дает результаты оценки как один из пяти уровней зрелости. Непрерывный подход дает один из четырех уровней возможностей. Различия в этих подходах ощущаются только при оценке; лучшие практики эквивалентны, приводя к эквивалентным результатам улучшения процессов.
 | Викискладе есть медиафайлы, связанные с Интеграция модели зрелости возможностей. |
