Модель зрелости интеграции - Capability Maturity Model Integration

"CMMI" перенаправляется сюда. Для правительственной организации США см. Центр инноваций Medicare и Medicaid.

Разработка программного обеспечения
Активность ядер
Парадигмы и модели
Методологии и рамки
Вспомогательные дисциплины
Практики
инструменты
Стандарты и свод знаний
Глоссарии
Контуры

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

Обзор

Характеристики уровней зрелости.[2]

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

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

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

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

CMMI темы

Представление

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

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

[9]

Фреймворк модели (v1.3)

Дальнейшая информация: Область процесса (CMMI)

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

Основные области процессов интеграции модели зрелости возможностей (CMMI)
СокращениеОбласть процессаКатегорияУровень зрелости
МАШИНАПричинно-следственный анализ и разрешениеПоддержка5
СМУправление конфигурациейПоддержка2
ДАРАнализ решений и разрешениеПоддержка3
IPMИнтегрированное управление проектамиУправление проектом3
MAИзмерение и анализПоддержка2
OPDОпределение организационного процессаУправление процессом3
ОБТКОриентация на организационный процессУправление процессом3
OPMУправление производительностью организацииУправление процессом5
OPPПроизводительность организационного процессаУправление процессом4
ОТОрганизационное обучениеУправление процессом3
ЧВКМониторинг и контроль проектаУправление проектом2
PPПланирование проектаУправление проектом2
PPQAОбеспечение качества процессов и продукцииПоддержка2
QPMКоличественное управление проектамиУправление проектом4
REQMУправление требованиямиУправление проектом2
РСКМУправление рискамиУправление проектом3
СЭМУправление соглашениями с поставщикамиПоддержка2

Уровни зрелости услуг

Ниже перечислены области процессов и уровни их зрелости для модели 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 для приобретения (CMMI-ACQ ), v1.3 была выпущена в ноябре 2010 года. В ней рассматриваются процессы управления цепочками поставок, приобретения и аутсорсинга в правительстве и промышленности.
  • CMMI для служб (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, для управления своей оценкой организации и составлением отчетов о выводах. Затем результаты оценки могут быть использованы (например, группой процессов) для планирования улучшений в организации.

В Стандартный метод оценки CMMI для улучшения процесса (SCAMPI) - это метод оценки, отвечающий всем требованиям ARC.[12] Результаты оценки SCAMPI могут быть опубликованы (если оцениваемая организация одобрит) на веб-сайте CMMI SEI: Опубликованные результаты оценки SCAMPI. SCAMPI также поддерживает проведение ISO / IEC 15504, также известен как СПЕЦИЯ (Улучшение программного процесса и определение возможностей), оценки и т. Д.

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

Для повышения уровня зрелости можно использовать методологию процесса разработки программного обеспечения группы Software Engineering Institute (SEI) и использование моделей CMMI. Новый продукт под названием «Метод ускоренного улучшения».[14] (AIM) сочетает в себе использование CMMI и TSP.[15]

Безопасность

Для решения проблем безопасности пользователей доступны два неофициальных руководства по безопасности. Рассмотрение аргументов в пользу безопасности содержимого в CMMI для служб имеет одну область процессов - Управление безопасностью.[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 и гибкая разработка программного обеспечения, оба подхода имеют много общего. Они считают, что ни то, ни другое не является «правильным» способом разработки программного обеспечения, но в проекте есть этапы, на которых один из двух лучше подходит. Они предлагают объединить различные фрагменты методов в новый гибридный метод. Sutherland et al. (2007) утверждают, что сочетание Scrum а CMMI обеспечивает большую адаптируемость и предсказуемость, чем любой другой.[19] Дэвид Дж. Андерсон (2005) дает советы о том, как интерпретировать CMMI в гибкой манере.[20]

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

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

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

Смотрите также

использованная литература

  1. ^ «Система электронного поиска товарных знаков (ТЭСС)». tmsearch.uspto.gov. Получено 21 декабря 2016.
  2. ^ а б c d Салли Годфри (2008) [software.gsfc.nasa.gov/docs/What%20is%20CMMI.ppt Что такое CMMI?]. Презентация НАСА. По состоянию на 8 декабря 2008 г.
  3. ^ «Институт CMMI - Главная».
  4. ^ «CMMI V1.3: Подведение итогов». Бен Линдерс. 10 января 2011 г.
  5. ^ «CMMI V1.3: Agile». Бен Линдерс. 20 ноября 2010 г.
  6. ^ «Выпущен CMMI V1.3: разъяснена высокая зрелость». Бен Линдерс. 2 ноября 2010 г.
  7. ^ «CMMI V1.3: Развертывание CMMI». Бен Линдерс. 16 ноября 2010 г.
  8. ^ Обзор CMMI. Институт программной инженерии. По состоянию на 16 февраля 2011 г.
  9. ^ https://www.cmmiinstitute.com/cmmi/model-viewer/appendices/a
  10. ^ «Области процессов CMMI V1.3». Бен Линдерс.
  11. ^ Последние опубликованные результаты аттестации CMMI см. Веб-сайт SEI В архиве 6 февраля 2007 г. Wayback Machine.
  12. ^ «Стандартный метод оценки CMMI для улучшения процесса (SCAMPISM) A, версия 1.2: документ с описанием метода». CMU / SEI-2006-HB-002. Институт программной инженерии. 2006 г.. Получено 23 сентября 2006.
  13. ^ «Профиль зрелости процесса». Получено 16 февраля 2011.
  14. ^ «Электронная библиотека ГЭИ». resources.sei.cmu.edu.
  15. ^ «Обзор TSP». resources.sei.cmu.edu.
  16. ^ Эйлир Форрестер и Киран Дойл. Рассмотрение аргументов в пользу безопасности содержимого в CMMI для служб (октябрь 2010 г.)
  17. ^ Корпоративные технологии Siemens AG. Обеспечение безопасности с помощью CMMI для разработки, версия 1.3, (Май 2013)
  18. ^ «Результаты работы CMMI CMMI». Получено 23 сентября 2006.
  19. ^ http://jeffsutherland.com/scrum/SutherlandScrumCMMIHICSSPID498889.pdf
  20. ^ Андерсон, Д. Дж. (20 июля 2005 г.). «Повышение гибкости до уровня CMMI 3 - история создания MSF для улучшения CMMI / spl reg / процессов в корпорации Microsoft». Конференция по гибкой разработке (ADC'05). С. 193–201. Дои:10.1109 / ADC.2005.42. ISBN  0-7695-2487-7. S2CID  5675994 - через IEEE Xplore.
  21. ^ «Дорожные карты CMMI». resources.sei.cmu.edu.
  22. ^ «CMMI V1.3: Дорожная карта проекта CMMI». Бен Линдерс. 7 декабря 2010 г.
  23. ^ «CMMI V1.3: Дорожные карты продуктов CMMI и интеграции продуктов». Бен Линдерс. 14 декабря 2010 г.
  24. ^ «CMMI V1.3: Дорожные карты процессов и измерений CMMI». Бен Линдерс. 28 декабря 2010 г.

Официальные источники

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

внешние ссылки