Модель зрелости интеграции

Интеграция модели зрелости возможностей ( CMMI ) - это программа обучения и оценки для улучшения уровня процессов. Под управлением CMMI института , в дочерней компании из ISACA , он был разработан в университете Карнеги - Меллона (CMU). Это требуется по многим правительственным контрактам США, особенно в разработке программного обеспечения.. CMU утверждает, что CMMI можно использовать для улучшения процессов в рамках проекта, подразделения или всей организации. CMMI определяет следующие уровни зрелости процессов: начальный, управляемый, определенный, количественно управляемый и оптимизационный. Версия 2.0 была опубликована в 2018 году (версия 1.3 была опубликована в 2010 году и является эталонной моделью для остальной информации в этой вики-статье). CMMI зарегистрирован в Управлении по патентам и товарным знакам США CMU. ^[1]

Обзор [ править ]

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

1. Разработка продуктов и услуг - CMMI for Development (CMMI-DEV),
2. Установление службы, управление, - CMMI для служб (CMMI-SVC) и
3. Приобретение продуктов и услуг - CMMI for Acquisition (CMMI-ACQ).

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

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

История [ править ]

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

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

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

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

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

Темы CMMI [ править ]

Представление [ править ]

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

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

^[9]

Фреймворк модели (v1.3) [ править ]

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

Уровни зрелости услуг [ править ]

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

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

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

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

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

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

• OPP - Производительность организационного процесса
• QWM - количественное управление работой

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

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

Модели (v1.3) [ править ]

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

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

Модель (v2.0) [ править ]

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

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

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

Оценка [ править ]

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

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

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

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

Стандартные СМГИ Оценка Методы процесса улучшения (SCAMPI) представляет собой метод оценки , который отвечает всем требования АРКА. ^[12] Результаты оценки SCAMPI могут быть опубликованы (если оцениваемая организация одобрит) на веб-сайте CMMI SEI: Опубликованные результаты оценки SCAMPI . SCAMPI также поддерживает выполнение ISO / IEC 15504 , также известного как SPICE (Улучшение программного процесса и определение возможностей), оценки и т. Д.

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

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

Безопасность [ править ]

Для решения проблем безопасности пользователей доступны два неофициальных руководства по безопасности. При рассмотрении аргументов в пользу безопасности в CMMI for Services есть одна область процессов - Управление безопасностью. ^[16] Разработанная безопасность с CMMI для разработки версии 1.3 включает следующие области процессов:

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

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

Приложения [ править ]

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

Turner & Jain (2002) утверждают, что, хотя очевидно, что между CMMI и гибкой разработкой программного обеспечения существуют большие различия , у обоих подходов много общего. Они считают, что ни то, ни другое не является «правильным» способом разработки программного обеспечения, но в проекте есть этапы, на которых один из двух лучше подходит. Они предлагают объединить различные фрагменты методов в новый гибридный метод. Сазерленд и др. (2007) утверждают, что комбинация Scrum и CMMI обеспечивает большую адаптируемость и предсказуемость, чем любая из них по отдельности. ^[19] Дэвид Дж. Андерсон (2005) дает советы о том, как интерпретировать CMMI в гибкой манере. ^[20]

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

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

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

См. Также [ править ]

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

Ссылки [ править ]

Официальные источники [ править ]

Отчеты SEI

• «CMMI для разработки, версия 1.3» . CMMI-DEV (версия 1.3, ноябрь 2010 г.) . Институт программной инженерии Университета Карнеги-Меллона. 2010 г.
• «CMMI для приобретения, версия 1.3» (PDF) . CMMI-ACQ (версия 1.3, ноябрь 2010 г.) . Институт программной инженерии Университета Карнеги-Меллона. 2010 г.
• «CMMI для служб, версия 1.3» . CMMI-SVC (версия 1.3, ноябрь 2010 г.) . Институт программной инженерии Университета Карнеги-Меллона. 2010 г.
• «Профиль зрелости процесса (текущие и прошлые версии)» . CMMI for Development SCAMPI Class A Appraisal Results . Институт программной инженерии.
• «Требования к оценке CMMI, версия 1.2 (ARC, V1.2)» (PDF) . Институт программной инженерии Университета Карнеги-Меллона. 2006 . Проверено 16 февраля 2011 года .
• «Стандартный метод оценки CMMI для улучшения процесса (SCAMPI) Версия 1.2: Документ с описанием метода» (док) . Институт программной инженерии Университета Карнеги-Меллона. 2006 г.
• CMMI Guidebook Acquirer Team (2007). «Понимание и использование усилий поставщика в области CMMI: руководство для покупателей» . CMU / SEI-2007-TR-004 . Институт программной инженерии.

Веб-страницы SEI

• «Информационный центр CMMI версии 1.3» . Институт программной инженерии. 2011 г.
• «Список партнеров SEI» . Институт программной инженерии . Проверено 28 октября 2006 года .
• «Официальное объявление Optimiza как CMMI-L3 и опубликовано на веб-сайте SEI» . Институт программной инженерии. Архивировано из оригинального 25 июля 2011 года . Проверено 15 марта 2011 года .
• Результаты оценки SCAMPI . Полный список SEI опубликованных результатов оценки SCAMPI.

Внешние ссылки [ править ]

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

• Официальный веб-сайт
• Интеграция модели зрелости возможностей в Curlie