Интеграция модели зрелости возможностей
| Часть серии о |
| Разработка программного обеспечения |
|---|
Интеграция модели зрелости возможностей ( CMMI ) — это программа обучения и оценки улучшения уровня процессов. Под управлением Института CMMI , дочерней компании ISACA , он был разработан в Университете Карнеги-Меллон (CMU). Это требуется во многих контрактах правительства США, особенно в области разработки программного обеспечения . CMU утверждает, что CMMI можно использовать для улучшения процессов в проекте, подразделении или всей организации.
CMMI определяет следующие пять уровней зрелости (от 1 до 5) для процессов: начальный, управляемый, определенный, количественно управляемый и оптимизация. Версия CMMI 3.0 была опубликована в 2023 году; [1] Версия 2.0 вышла в 2018 году; Версия 1.3 была опубликована в 2010 году и является эталонной моделью для остальной информации в этой статье. CMMI зарегистрирован в Ведомстве по патентам и товарным знакам США компанией CMU. [2]
Обзор
[ редактировать ]
Первоначально CMMI обращается к трем областям интересов:
- Разработка продуктов и услуг – CMMI для развития (CMMI-DEV),
- Создание и управление услугами – CMMI для услуг (CMMI-SVC) и
- Приобретение продуктов и услуг – 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 для разработки версий 1.2 и 1.3. Публикация Аддисона-Уэсли версии 1.3 была посвящена памяти Уоттса Хамфри. Эйлин К. Форрестер, Брэндон Л. Буто и Сэнди Шрам были авторами печатной публикации CMMI for Services версии 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]
Структура модели (v1.3)
[ редактировать ]В зависимости от используемых областей интересов (приобретение, услуги, разработка) содержащиеся в нем области процессов будут различаться. [11] Области процессов — это области, которые будут охвачены процессами организации. В таблице ниже перечислены семнадцать основных областей процессов CMMI, которые присутствуют во всех интересующих областях CMMI в версии 1.3.
| Аббревиатура | Область процесса | Категория | Уровень зрелости |
|---|---|---|---|
| МАШИНА | Причинный анализ и разрешение | Поддерживать | 5 |
| СМ | Управление конфигурацией | Поддерживать | 2 |
| НО | Анализ решений и разрешение | Поддерживать | 3 |
| ИПМ | Интегрированное управление проектами | Управление проектом | 3 |
| И | Измерение и анализ | Поддерживать | 2 |
| ОПД | Определение организационного процесса | Управление процессами | 3 |
| ОБТК | Фокус организационного процесса | Управление процессами | 3 |
| ОПМ | Управление организационной эффективностью | Управление процессами | 5 |
| ВВЕРХ | Эффективность организационного процесса | Управление процессами | 4 |
| OT | Организационное обучение | Управление процессами | 3 |
| ЧВК | Мониторинг и контроль проекта | Управление проектом | 2 |
| ПП | Планирование проекта | Управление проектом | 2 |
| PPQA | Обеспечение качества процессов и продукции | Поддерживать | 2 |
| QPM | Количественное управление проектами | Управление проектом | 4 |
| РЕМК | Управление требованиями | Управление проектом | 2 |
| РСКМ | Управление рисками | Управление проектом | 3 |
| ОДИН | Управление соглашениями с поставщиками | Поддерживать | 2 |
Уровни зрелости услуг
[ редактировать ]Ниже перечислены области процессов и уровни их зрелости для модели CMMI для услуг:
Уровень зрелости 2 – Управляемый
- CM – Управление конфигурацией
- MA – Измерение и анализ
- PPQA – Обеспечение процессов и качества
- REQM – Управление требованиями
- SAM – Управление соглашениями с поставщиками
- СД – Предоставление услуг
- WMC – Мониторинг и контроль работ
- WP – Планирование работы
Уровень зрелости 3 – Определен
- CAM – Управление емкостью и доступностью
- DAR – Анализ и разрешение решений
- IRP – Разрешение и предотвращение инцидентов
- IWM – Интегрированное управление работами
- OPD – Определение организационного процесса
- OPF – Фокус на организационных процессах...
- ОТ – Организационное обучение
- РСКМ – Управление рисками
- SCON – Непрерывность обслуживания
- SSD – Разработка сервисной системы
- SST – Переход на систему обслуживания
- STSM – Стратегическое управление услугами
Уровень зрелости 4 – Количественно управляемый
- OPP – Эффективность организационного процесса
- QWM – Количественное управление работами
Уровень зрелости 5 – Оптимизация
- CAR – Причинный анализ и разрешение.
- OPM – Управление эффективностью организации.
Модели (v1.3)
[ редактировать ]Лучшие практики CMMI публикуются в документах, называемых моделями, каждая из которых касается отдельной области интересов. Версия 1.3 предоставляет модели для трех областей интересов: разработка, приобретение и обслуживание.
- CMMI for Development (CMMI-DEV), v1.3, был выпущен в ноябре 2010 года. Он касается процессов разработки продуктов и услуг.
- CMMI for Acquisition (CMMI-ACQ), v1.3, был выпущен в ноябре 2010 года. Он предназначен для управления цепочками поставок, процессов приобретения и аутсорсинга в правительстве и промышленности.
- CMMI for Services (CMMI-SVC), версия 1.3, была выпущена в ноябре 2010 года. В ней содержатся рекомендации по предоставлению услуг внутри организации и внешним клиентам.
Модель (v2.0)
[ редактировать ]В версии 2.0 DEV, ACQ и SVC были объединены в единую модель, где каждая область процесса потенциально имеет конкретную ссылку на один или несколько из этих трех аспектов. Чтобы идти в ногу с отраслью, модель также явно ссылается на аспекты гибкости в некоторых областях процессов.
Некоторые ключевые различия между моделями v1.3 и v2.0 приведены ниже:
- «Области процессов» были заменены «Областями практики (PA)». Последнее организовано по уровням, а не по «конкретным целям».
- Каждый PA состоит из «ядра» (т. е. общего и не терминологического описания) и «контекстно-зависимого» (т. е. описания с точки зрения Agile/Scrum, разработки, услуг и т. д.).
- Поскольку соблюдение всех правил теперь является обязательным, раздел «Ожидаемые» был удален.
- «Общие практики» были помещены в новую область под названием «Инфраструктура управления и реализации», а «Специальные практики» были опущены.
- Особое внимание уделяется обеспечению выполнения ПА и их постоянной практике, пока они не станут «привычкой».
- Все уровни зрелости сосредоточены на ключевом слове «производительность».
- Включены два и пять дополнительных PA из области «Безопасность» и «Охрана».
- Области процессов PCMM были объединены.
Оценка
[ редактировать ]Организация не может быть сертифицирована по CMMI; организация вместо этого оценивается . В зависимости от типа оценки организации может быть присвоен рейтинг уровня зрелости (1–5) или профиль достижения уровня возможностей.
Многие организации находят ценность в измерении своего прогресса путем проведения оценки. Оценки обычно проводятся по одной или нескольким из следующих причин:
- Определить, насколько процессы организации соответствуют передовым практикам CMMI, и определить области, где можно внести улучшения.
- Информировать внешних клиентов и поставщиков о том, насколько процессы организации соответствуют лучшим практикам CMMI.
- Для удовлетворения договорных требований одного или нескольких клиентов
Оценка организаций с использованием модели CMMI [12] должен соответствовать требованиям, определенным в документе «Требования к оценке для CMMI (ARC)». Существует три класса оценок: A, B и C, которые направлены на выявление возможностей улучшения и сравнение процессов организации с лучшими практиками CMMI. Из них оценка класса А является наиболее формальной и единственной, которая может привести к присвоению рейтинга уровня. Оценочные группы используют модель CMMI и метод оценки, соответствующий ARC, для оценки организации и составления отчетов о выводах. Результаты оценки затем могут быть использованы (например, группой процессов) для планирования улучшений организации.
Стандартный метод оценки CMMI для улучшения процессов (SCAMPI) — это метод оценки, который отвечает всем требованиям ARC. [13] Результаты оценки SCAMPI могут быть опубликованы (если оцениваемая организация одобряет) на веб-сайте CMMI SEI: Опубликованные результаты оценки SCAMPI. SCAMPI также поддерживает проведение оценок и т. д. по стандарту ISO/IEC 15504 , также известному как SPICE (улучшение и определение возможностей программного обеспечения).
Этот подход способствует обучению членов EPG и PAT работе с CMMI, проведению неформальной оценки (SCAMPI C) и определению приоритетных областей процесса для улучшения. Более современные подходы, предполагающие внедрение коммерчески доступных процессов, совместимых с CMMI, могут значительно сократить время достижения соответствия. SEI ведет статистику о «времени перехода» для организаций, использующих более раннюю версию программного обеспечения CMM, а также CMMI. [14] Эти статистические данные показывают, что с 1987 года среднее время перехода с уровня 1 на уровень 2 составляет 23 месяца, а с уровня 2 на уровень 3 — еще 20 месяцев. С момента выпуска CMMI среднее время перехода с уровня 1 на уровень 2 составляет 5 месяцев, а среднее время перехода на уровень 3 — еще 21 месяц. Эта статистика обновляется и публикуется каждые шесть месяцев в профиле погашения. [ нужна ссылка ]
Для повышения уровня зрелости можно использовать методологию разработки программного обеспечения Института программной инженерии (SEI) и использование моделей CMMI. Новый продукт под названием «Метод ускоренного улучшения». [15] (AIM) сочетает в себе использование CMMI и TSP. [16]
Безопасность
[ редактировать ]Для решения проблем безопасности пользователей доступны два неофициальных руководства по безопасности. Рассмотрение аргументов в пользу безопасности Содержимое в CMMI for Services имеет одну область процесса — Управление безопасностью. [17] Безопасность по проекту с CMMI для разработки, версия 1.3 имеет следующие области процессов:
- OPSD – Организационная готовность к безопасному развитию
- SMP – безопасное управление проектами
- СРТС – Требования безопасности и техническое решение
- SVV – проверка и валидация безопасности
Хотя они не влияют на уровень зрелости или возможностей, эти области процессов могут быть отражены в результатах оценки. [18]
Приложения
[ редактировать ]SEI опубликовало исследование, в котором говорится, что 60 организаций зафиксировали повышение производительности в таких категориях, как затраты, график, производительность, качество и удовлетворенность клиентов. [19] Медианное увеличение производительности варьировалось от 14% (удовлетворенность клиентов) до 62% (производительность). Однако модель CMMI в основном касается того, какие процессы следует реализовать, а не столько того , как их можно реализовать. Эти результаты не гарантируют, что применение CMMI повысит производительность в каждой организации. Небольшая компания с небольшими ресурсами может с меньшей вероятностью получить выгоду от CMMI; это представление поддерживается профилем зрелости процесса (стр. 10). Из малых организаций (<25 сотрудников) 70,5% оцениваются на уровне 2: Управляемый, а 52,8% организаций с численностью 1001–2000 сотрудников оцениваются на самом высоком уровне (5: Оптимизирующий).
Тернер и Джейн (2002) утверждают, что, хотя очевидно, что существуют большие различия между CMMI и гибкой разработкой программного обеспечения , оба подхода имеют много общего. Они считают, что ни один из этих способов не является «правильным» при разработке программного обеспечения, но в проекте есть этапы, когда один из двух подходит лучше. Они предлагают объединить различные фрагменты методов в новый гибридный метод. Сазерленд и др. (2007) утверждают, что сочетание Scrum и CMMI обеспечивает большую адаптивность и предсказуемость, чем каждый из них по отдельности. [20] Дэвид Дж. Андерсон (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 можно оценить с использованием двух разных подходов: поэтапного и непрерывного. Поэтапный подход дает результаты оценки как один из пяти уровней зрелости. Непрерывный подход дает один из четырех уровней возможностей. Различия этих подходов ощущаются лишь в оценке; лучшие практики эквивалентны, что приводит к эквивалентным результатам улучшения процессов.
См. также
[ редактировать ]- Модель незрелости возможностей
- Модель зрелости возможностей
- Структура оценки архитектуры предприятия
- ЛинCMMI
- Модель зрелости способностей людей
- Группа процессов разработки программного обеспечения
Ссылки
[ редактировать ]- ^ «Изменения контента CMMI. Выпуск: V3.0, 6 апреля 2023 г.» . Институт CMMI.
- ^ «Система электронного поиска товарных знаков (TESS)» . tmsearch.uspto.gov . Проверено 21 декабря 2016 г.
- ^ Перейти обратно: а б с д Салли Годфри (2008) [software.gsfc.nasa.gov/docs/What%20is%20CMMI.ppt Что такое CMMI?]. Презентация НАСА. По состоянию на 8 декабря 2008 г.
- ^ «Институт CMMI – Домой» .
- ^ «CMMI V1.3: Подведение итогов» . Бен Линдерс . 10 января 2011 г.
- ^ «CMMI V1.3: Agile» . Бен Линдерс . 20 ноября 2010 г.
- ^ «Выпущен CMMI V1.3: разъяснения относительно высокой зрелости» . Бен Линдерс . 2 ноября 2010 г.
- ^ «CMMI V1.3: Развертывание CMMI» . Бен Линдерс . 16 ноября 2010 г.
- ^ Обзор CMMI . Институт программной инженерии. По состоянию на 16 февраля 2011 г.
- ^ «Институт CMMI - Основные области практики, категории и области возможностей» . Архивировано из оригинала 16 декабря 2018 года . Проверено 15 декабря 2018 г.
- ^ «Области процесса CMMI V1.3» . Бен Линдерс . 18 сентября 2023 г.
- ^ Последние опубликованные результаты оценки CMMI см. на веб-сайте SEI. Архивировано 6 февраля 2007 г. на Wayback Machine .
- ^ «Стандартный метод оценки CMMI для улучшения процессов (SCAMPISM) A, версия 1.2: Документ с определением метода» . CMU/SEI-2006-HB-002 . Институт программной инженерии. 2006 год . Проверено 23 сентября 2006 г.
- ^ «Профиль зрелости процесса» . Проверено 16 февраля 2011 г.
- ^ «Цифровая библиотека ГЭИ» . resources.sei.cmu.edu . 9 февраля 2024 г.
- ^ «Обзор ТСП» . resources.sei.cmu.edu . 13 сентября 2010 г.
- ^ Эйлер Форрестер и Киран Дойл. Рассмотрение аргументов в пользу содержимого безопасности в CMMI для служб (октябрь 2010 г.)
- ^ Корпоративные технологии Siemens AG. Задуманная безопасность с CMMI для разработки, версия 1.3 (май 2013 г.)
- ^ «Результаты производительности CMMI CMMI» . Проверено 23 сентября 2006 г.
- ^ Сазерленд, Джефф; Русенг Якобсен, Карстен; Джонсон, Кент. «Scrum и CMMI, уровень 5: волшебное зелье для специалистов по кодированию» (PDF) . Объектная технология Джефф Сазерленд .
- ^ Андерсон, диджей (20 июля 2005 г.). «Расширение Agile до уровня 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.
- ^ «Дорожные карты CMMI» . resources.sei.cmu.edu . 31 октября 2008 г.
- ^ «CMMI V1.3: Дорожная карта проекта CMMI» . Бен Линдерс . 7 декабря 2010 г.
- ^ «CMMI V1.3: Дорожные карты продуктов CMMI и интеграции продуктов» . Бен Линдерс . 14 декабря 2010 г.
- ^ «CMMI V1.3: Дорожные карты процессов и измерений CMMI» . Бен Линдерс . 28 декабря 2010 г.
- ^ «Использование CMMI для улучшения управления прибавочной стоимостью» . resources.sei.cmu.edu . 30 сентября 2002 года . Проверено 30 июня 2022 г.
Внешние ссылки
[ редактировать ]
| Базы данных органов управления : Национальные |
|---|
